I've discovered the cause of this error. Using Special:RunQuery inside of the Template used to format the results of said query/form will throw this error.

I was trying to place a Special:RunQuery search box on the results page somewhere other than the top or bottom.

{{Special:RunQuery/_formname_}}

Full template can be found here: http://pastebin.com/uNALQimx

The same thing occurs to me.

Semantic Forms: 2.8 (8239268)
MediaWiki: 1.24alpha (c0bd3b7)

Error message:

MediaWiki internal error.

Original exception: [928a2657] [no req]
Exception from line 6347 of /w/includes/parser/Parser.php:
Parser state cleared while parsing. Did you call Parser::parse recursively?
Backtrace:
#0 /w/includes/parser/Parser.php(374): Parser->lock()
#1 /w/extensions/SemanticForms/includes/SF_FormUtils.php(428): Parser->parse(string, Title, ParserOptions)
#2 /w/extensions/SemanticForms/includes/SF_FormPrinter.php(501): SFFormUtils::getFormDefinition(Parser, string, integer)
#3 /w/extensions/SemanticForms/specials/SF_RunQuery.php(79): SFFormPrinter->formHTML(string, boolean, boolean, integer, NULL, NULL, NULL, boolean, boolean)
#4 /w/extensions/SemanticForms/specials/SF_RunQuery.php(30): SFRunQuery->printPage(string, boolean)
#5 /w/includes/specialpage/SpecialPage.php(363): SFRunQuery->execute(string)
#6 /w/includes/specialpage/SpecialPageFactory.php(562): SpecialPage->run(string)
#7 /w/includes/specialpage/SpecialPageFactory.php(601): SpecialPageFactory::executePath(Title, RequestContext, boolean)
#8 /w/includes/parser/Parser.php(3549): SpecialPageFactory::capturePath(Title, RequestContext)
#9 /w/includes/parser/Preprocessor_DOM.php(1179): Parser->braceSubstitution(array, PPFrame_DOM)
#10 /w/includes/parser/Parser.php(3281): PPFrame_DOM->expand(PPNode_DOM, integer)
#11 /w/includes/parser/Parser.php(1239): Parser->replaceVariables(string)
#12 /w/includes/parser/Parser.php(405): Parser->internalParse(string)
#13 [internal function]: Parser->parse(string, Title, ParserOptions, boolean, boolean, integer)
#14 /w/includes/StubObject.php(105): call_user_func_array(array, array)
#15 /w/includes/StubObject.php(125): StubObject->_call(string, array)
#16 /w/includes/content/WikitextContent.php(338): StubObject->__call(string, array)
#17 /w/includes/content/WikitextContent.php(338): StubObject->parse(string, Title, ParserOptions, boolean, boolean, integer)
#18 /w/includes/content/AbstractContent.php(490): WikitextContent->fillParserOutput(Title, integer, ParserOptions, boolean, ParserOutput)
#19 /w/includes/poolcounter/PoolWorkArticleView.php(139): AbstractContent->getParserOutput(Title, integer, ParserOptions)
#20 /w/includes/poolcounter/PoolCounterWork.php(123): PoolWorkArticleView->doWork()
#21 /w/includes/page/WikiPage.php(1173): PoolCounterWork->execute()
#22 /w/includes/diff/DifferenceEngine.php(615): WikiPage->getParserOutput(ParserOptions, integer)
#23 /w/includes/diff/DifferenceEngine.php(592): DifferenceEngine->getParserOutput(WikiPage, Revision)
#24 /w/includes/diff/DifferenceEngine.php(451): DifferenceEngine->renderNewRevision()
#25 /w/includes/page/Article.php(809): DifferenceEngine->showDiffPage(boolean)
#26 /w/includes/page/Article.php(515): Article->showDiffPage()
#27 /w/includes/actions/ViewAction.php(44): Article->view()
#28 /w/includes/MediaWiki.php(414): ViewAction->show()
#29 /w/includes/MediaWiki.php(282): MediaWiki->performAction(Article, Title)
#30 /w/includes/MediaWiki.php(584): MediaWiki->performRequest()
#31 /w/includes/MediaWiki.php(435): MediaWiki->main()
#32 /w/index.php(46): MediaWiki->run()
#33 {main}

Exception caught inside exception handler: [9a57f917] [no req] Exception from line 1287 of /w/includes/WebRequest.php: FauxRequest::getRequestURL() not implemented
Backtrace:
#0 /w/includes/WebRequest.php(1338): FauxRequest->notImplemented(string)
#1 /w/includes/skins/SkinTemplate.php(1147): FauxRequest->getRequestURL()
#2 /w/includes/skins/SkinTemplate.php(523): SkinTemplate->buildContentNavigationUrls()
#3 /w/includes/skins/SkinTemplate.php(274): SkinTemplate->prepareQuickTemplate(OutputPage)
#4 /w/includes/OutputPage.php(2186): SkinTemplate->outputPage()
#5 /w/includes/exception/MWException.php(195): OutputPage->output()
#6 /w/includes/exception/MWException.php(238): MWException->reportHTML()
#7 /w/includes/exception/MWExceptionHandler.php(45): MWException->report()
#8 /w/includes/exception/MWExceptionHandler.php(141): MWExceptionHandler::report(MWException)
#9 /w/includes/MediaWiki.php(449): MWExceptionHandler::handle(MWException)
#10 /w/index.php(46): MediaWiki->run()
#11 {main}

Yes, trying to embed Special:RunQuery has led to problems for a while now - and it seems to have gotten worse since MediaWiki 1.24, when calling the parser within a wiki page has apparently become all but impossible. I need to better understand the parser changes that happened in 1.24, but I'm not optimistic about this specific issue.

If I change line 428 in extensions/SemanticForms/includes/SF_FormUtils.php:
$output = $parser->parse( $form_def, $title, $parser->getOptions());
to
$output = $parser->parse( $form_def, $title, $parser->getOptions(), true, false);
Special:RunQuery works as expected. Or it seems so at least.

But what did I do? I changed the parameter $clearState of parse() to something else than its default of 'true'. What does $clearState mean in this context?

Hi Yaron, can you please comment on Masin's comment? Is it a solution? I can't tell myself... Thanks!
Best, Silke

Oh, I didn't realize that the previous post was a proposed solution. It's great that this may fix the issue. I'm adding Stephan to this discussion - parser stuff in SF is essentially his work. Stephan, what do you think?

Meanwhile, I have been told extensions shouldn't use Parser::parse() at all but rather Parser::recursiveTagParse(). So I changed those lines in SF_FormUtils.php to:

		$output = $parser->recursiveTagParse( $form_def );
		$form_def = $stripState->unstripGeneral( $output );

As I don't fully understand the neccessities of the following lines, I commented them out. recursiveTagParse does not return a ParserOutput object, so adapting those lines doesn't look feasible at all.

/* if ( $output->getCacheTime() == -1 ) {

			$form_article = Article::newFromID( $form_id );
			self::purgeCache( $form_article );
			wfDebug( "Caching disabled for form definition $form_id\n" );
		} elseif ( $form_id !== null ) {
			self::cacheFormDefinition( $form_id, $form_def, $parser );
		}*/

Result: Works as well with our usecase. There might be some ratio to using Parser::parse() instead of Parser::recursiveTagParse() but I can't see it at the moment.

Masin - thanks for looking into this, and sorry about the delay. In your code, you seem to have hit on the main reason for using parse() instead of recursiveTagParse(), which is that it allows for caching forms. I would hate to remove the caching functionality unless it's necessary... would you say your earlier solution, of adding more arguments into the parse() call, is a complete solution in itself?

Is this bug still present? I've found in another bit of code that there is a recursive version for $parser->preprocess called parser->recursivePreprocess(). Maybe it's a fix?

It is not present in Page Forms 4.6 (MediaWiki 1.33.0). Not tested in newer versions (but, I believe it is not present either).