Last modified: 2011-07-07 17:29:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 16129 - Transcluded special pages expose strip markers when they output parsed messages
Transcluded special pages expose strip markers when they output parsed messages
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.14.x
All All
: Normal normal with 5 votes (vote)
: ---
Assigned To: Sam Reed (reedy)
http://iu.wikipedia.org/w/index.php?t...
: parser
: 20689 22081 23207 (view as bug list)
Depends on: 17329 28532
Blocks: 18941 UNIQ 16744 23293
  Show dependency treegraph
 
Reported: 2008-10-26 14:23 UTC by Splarka
Modified: 2011-07-07 17:29 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Splarka 2008-10-26 14:23:25 UTC
Minimal test case:

 </div>{{Special:Newpages}}

The div is not tidied or sanitized. There needs to be no new pages in the Recent Changes table for this to occur. Observed on iu.wikipedia (test URI may be unbroken if a new page is in the RC table). The extra closing tag and the transclusion of Newpages were quite far apart as well.
Comment 1 Splarka 2008-12-20 04:44:53 UTC
Another example:

 <nowiki>foo</nowiki> {{Special:Newpages/limit=5,offset=10000,shownav}}

Causes nowiki to UNIQ-QINU out, but only if it preceeds the zero'd report
Comment 2 Splarka 2008-12-20 08:04:33 UTC
WTFBBQ: http://en.wikipedia.org/w/api.php?action=parse&text=%7B%7BSpecial%3ANewpages%2Foffset%3D-1%7D%7D

<error code="internal_api_error_MWException" info="Exception Caught: Empty $wgTitle in OutputPage::parse">
Comment 3 Roan Kattouw 2008-12-20 11:25:02 UTC
(In reply to comment #2)
> WTFBBQ:
> http://en.wikipedia.org/w/api.php?action=parse&text=%7B%7BSpecial%3ANewpages%2Foffset%3D-1%7D%7D
> 
> <error code="internal_api_error_MWException" info="Exception Caught: Empty
> $wgTitle in OutputPage::parse">
> 

That's technically not an API bug. When $wgParser->mTitle is set, the parser should respect that and not be stubborn and use $wgTitle instead. I'll fix it by setting $wgTitle explicitly anyway, but note that this breaks parsing a non-$wgTitle page, which should be possible.
Comment 4 Roan Kattouw 2008-12-20 20:01:19 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > WTFBBQ:
> > http://en.wikipedia.org/w/api.php?action=parse&text=%7B%7BSpecial%3ANewpages%2Foffset%3D-1%7D%7D
> > 
> > <error code="internal_api_error_MWException" info="Exception Caught: Empty
> > $wgTitle in OutputPage::parse">
> > 
> 
> That's technically not an API bug. When $wgParser->mTitle is set, the parser
> should respect that and not be stubborn and use $wgTitle instead. I'll fix it
> by setting $wgTitle explicitly anyway, but note that this breaks parsing a
> non-$wgTitle page, which should be possible.
> 

This particular issue was fixed in r44858, bug as reported is still unresolved.
Comment 5 Splarka 2008-12-20 21:03:25 UTC
More testing:

This also affects {{Special:NewImages}} (such as on a wiktionary with no images) the same. They have addWikiMsg() in common for zero results. It also exposes strip markers for all tested parser extension tags that appear *before* the call (but not after?). Renaming bug to clarify.

{{Special:Prefixindex}} and {{Special:Recentchanges}} are not affected. I don't know how to get {{Special:Allpages}} to return zero results.
Comment 6 Gurch 2008-12-20 21:16:01 UTC
(In reply to comment #5)
> I don't know how to get {{Special:Allpages}} to return zero results.

Might be possible by using 'Show preview' and a wiki with no pages.
Comment 7 Roan Kattouw 2008-12-21 19:33:12 UTC
Bug 16744 may be related.
Comment 8 P.Copp 2008-12-21 19:58:20 UTC
(In reply to comment #5)
> More testing:
> 
> This also affects {{Special:NewImages}} (such as on a wiktionary with no
> images) the same. They have addWikiMsg() in common for zero results. It also
> exposes strip markers for all tested parser extension tags that appear *before*
> the call (but not after?). Renaming bug to clarify.
Right. addWikiMsg() calls wfMsgExt() with option 'parse' so we have another case of recursively calling $wgParser->parse() which should be avoided.

Fix could be to simply not output the message if the special page is included.
Comment 9 Brion Vibber 2008-12-22 19:19:24 UTC
Tim, can you take a look at this?
Comment 10 MZMcBride 2009-02-18 23:26:31 UTC
Another test case:

== Foo ==
{{Special:OldReviewedPages/limit=3,category=Biblia}}

This is causing strip markers to be exposed on pl.wikipedia.org.
Comment 11 Leinad 2009-02-19 15:55:22 UTC
(In reply to comment #10)
> Another test case:
> 
> == Foo ==
> {{Special:OldReviewedPages/limit=3,category=Biblia}}
> 
> This is causing strip markers to be exposed on pl.wikipedia.org.
> 

It appears also on other wikis, where is enabled FlaggedRevs.
Comment 12 Greg Rundlett 2009-02-22 15:25:42 UTC
There is also a discussion of this at http://www.mediawiki.org/wiki/QINU_fix -- I'll add a link there into 17329 so Googlers find good info about the fix
Comment 13 Splarka 2009-04-21 10:00:21 UTC
Anyone know if bug 16744 is a duplicate or is it a different problem?
Comment 14 P.Copp 2009-04-25 08:02:35 UTC
Not really a dupe IMHO (bug 16744 is fixed, this one not yet), but the same basic problem, yes. See bug 17329 for some thoughts on the topic.
Comment 15 Splarka 2009-08-18 00:48:23 UTC
Addendum: this seems to happen in Special:Newpages when an edit (page creation in this case) gets tagged, such as via an extension like Abuse Filter.
Comment 16 Leinad 2009-09-17 13:52:31 UTC
*** Bug 20689 has been marked as a duplicate of this bug. ***
Comment 17 P.Copp 2010-01-11 21:47:24 UTC
*** Bug 22081 has been marked as a duplicate of this bug. ***
Comment 18 Tim Starling 2010-03-30 03:45:01 UTC
The simplest fix would be to make wfMsgExt() use the same parser instance as the one MessageCache::transform() uses. The reason MessageCache::transform() goes to all the trouble of setting up a separate parser instance is to avoid bugs like this.
Comment 19 Bawolff (Brian Wolff) 2010-04-18 05:38:58 UTC
*** Bug 23207 has been marked as a duplicate of this bug. ***
Comment 20 Sam Reed (reedy) 2011-04-15 17:45:22 UTC
Adding dependancy against bug 28532, as that seems to be the action item for this bug
Comment 21 Sam Reed (reedy) 2011-04-18 12:44:42 UTC
r86304
Comment 22 Mark A. Hershberger 2011-07-07 14:37:50 UTC
http://en.wikipedia.org/wiki/User:MarkAHershberger/Bug_Examples#bogus_heading_to_demo_next_bug

Maybe Reedy's fix wasn't merged to 1.17wmf1
Comment 23 Sam Reed (reedy) 2011-07-07 17:22:02 UTC
Indeed, but it's also not been fully reviewed

Tag for backport if necessary (not all bug fixes have to be), don't need to reopen the bug

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links