UNIQ key exposed when feeding strip markers into {{#tag:source
OpenPublic

Description

If an <nowiki> and firends is used inside an function, then instead of generating a result, the UNIQ key is exposed instead, for example: "{{#tag:source|<nowiki>foo</nowiki>|lang=java}}" gives UNIQ7f095fb854002218-nowiki-00000000-QINU in one instance.


Version: unspecified
Severity: normal
URL: http://en.wikipedia.org/wiki/User:AzaToth/X23

bzimport set Reference to bz14562.
AzaToth created this task.Via LegacyJun 16 2008, 5:22 PM
aaron added a comment.Via ConduitSep 12 2008, 2:41 PM

I can repro with cite tags too

tstarling added a comment.Via ConduitSep 12 2008, 2:44 PM

The convention is that text inserted into the unstrip array should be fully unstripped already. This is because unstrip() is a performance hotspot, much more common than strip item insertion, so it makes sense to perform as much of the processing as possible during insertion.

MarkAHershberger added a comment.Via ConduitDec 2 2010, 8:20 PM

Confirmed this with the latest SyntaxHighlight_GeSHi and SVN HEAD, but not with Cite.

MarkAHershberger added a comment.Via ConduitApr 12 2011, 4:37 PM

Re-classifying as a SyntaxHighlight_GeSHi problem. It should be fixed there, not in core MW.

MarkAHershberger added a comment.Via ConduitMay 3 2011, 5:43 PM

Assigning to robla since this is a "high" priority and X!'s user page says he is extremely busy IRL as of 17:57, 20 March 2011 (UTC)

tstarling added a comment.Via ConduitJul 7 2011, 7:03 AM

Why is it a high priority?

MarkAHershberger added a comment.Via ConduitJul 7 2011, 2:23 PM

(In reply to comment #6)

Why is it a high priority?

These sort of niggling little problems are piling up. Perhaps this particular one is something that we can live without fixing RIGHT now, but AFAICT, this and other dependencies of Bug #26213 are going to keep coming until we have something to tell authors to look for when trying to solve the problem or to test for when writing new code.

The priority was set after a triage that said deployed extensions are higher priority. This bug is on a deployed extension. See http://www.mediawiki.org/wiki/User:MarkAHershberger/BugDemo#Bug_14562 Also on that page, a demonstration of Bug #22555 which is a problem with ParserFunctions and can also be seen on Wikipedia: http://en.wikipedia.org/wiki/User:MarkAHershberger/Bug_Examples#Bug_14562

Reading back through the reports it is clear that some users think their wikitext is at fault ('basically a big flashing sign that says "BAD WIKICODE HERE".')

Ideally, I'd like to do a sprint to fix Bug #26213. This bug is a good place to start.

RobLa-WMF added a comment.Via ConduitJul 7 2011, 5:19 PM

Mark and I discussed this one. This bug is going to low priority, because it's relatively minor, but there is some UNIQ cleanup work that could be high priority.

gerritbot added a comment.Via ConduitJun 20 2014, 8:45 PM

Change 141056 had a related patch set uploaded by Brian Wolff:
Prevent OutputPage::addWikiText and friends from causing UNIQ fails

https://gerrit.wikimedia.org/r/141056

gerritbot added a comment.Via ConduitJun 26 2014, 9:25 AM

Change 141056 merged by jenkins-bot:
Prevent OutputPage::addWikiText and friends from causing UNIQ fails

https://gerrit.wikimedia.org/r/141056

Nemo_bis added a comment.Via ConduitJun 26 2014, 7:36 PM

Approved by Nikerabbit and translatewiki.net didn't explode.

Bawolff added a comment.Via ConduitJun 26 2014, 8:26 PM

whoops, what am I doing. This one has a different cause for the UNIQ's. That patch won't fix it.

Qgil added subscribers: Bawolff, Qgil.Via WebJan 12 2015, 12:13 PM

@Bawolff, this is one of the oldest tasks assigned to someone. Are you planning to work on it, and is its current priority correct?

MarkAHershberger removed a subscriber: MarkAHershberger.Via WebJan 12 2015, 2:38 PM
Bawolff added a comment.Via WebJan 14 2015, 3:26 PM

@Qgil I didn't even realize this was assigned to me (Its all Nemo's fault! (jk))

Basically this got assigned to me, because I submitted a patch, which got merged, and then the bug got marked fixed and at that time we were following the convention that bugs should be assigned to someone once they fix it. But then bug got re-opened (because I was actually fixing a different bug) and I was still assigned and didn't realize it.

I agree with priority. Without looking at the code, one could probably fix this by just doing unstrip on the input to the source tag, so probably not that hard a bug. However I don't have any plans to work on it right now.

Bawolff placed this task up for grabs.Via WebJan 14 2015, 3:26 PM
Bawolff set Security to None.

Add Comment