Page MenuHomePhabricator

Transcluded special pages expose strip markers when they output parsed messages
Closed, ResolvedPublic

Description

Author: herd

Description:
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.


Version: 1.14.x
Severity: normal
URL: http://iu.wikipedia.org/w/index.php?title=%E1%90%8A%E1%92%A5%E1%96%85/amiq&oldid=13848

Details

Reference
bz16129

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:21 PM
bzimport set Reference to bz16129.

herd wrote:

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

herd wrote:

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">

(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.

(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.

herd wrote:

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.

matthew.britton wrote:

(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.

(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.

Tim, can you take a look at this?

Another test case:

Foo

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

This is causing strip markers to be exposed on pl.wikipedia.org.

danny.leinad wrote:

(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.

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

herd wrote:

Anyone know if bug 16744 is a duplicate or is it a different problem?

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.

herd wrote:

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.

danny.leinad wrote:

*** Bug 20689 has been marked as a duplicate of this bug. ***

*** Bug 22081 has been marked as a duplicate of this bug. ***

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.

  • Bug 23207 has been marked as a duplicate of this bug. ***

Adding dependancy against bug 28532, as that seems to be the action item for this bug

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