Page MenuHomePhabricator

Two exclamation points in the display text of a wikilink interpreted as table markup
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

What happens?:
In diagnosing Linter errors, I found a table like this one in the wild.

The original wikitext, stripped down a bit for simplicity, looked like this:

{|  style="width: 100%; "
|-
! class="" style="font-weight:bold"| Resolved comments <small>([[User talk:Example|Bar!!]])</small> 20:16, 14 April 2020 (UTC)
|-
|Foo
|}

Note the two exclamation points in the display text portion of the wikilink. As you can see if you click through the link above, I'm seeing a couple of different things happen:

  1. The trailing /small tag is not rendered (after the closing paren, before the time portion of the date stamp) when I wrap the above code in syntaxhighlight tags. (This happens only if you have the "Change UTC-based times and dates, such as those used in signatures, to be relative to local time" gadget enabled in Preferences, so there may be another bug there.)
  2. When the table is rendered, the two exclamation points, even though they are in a wikilink, appear to be interpreted as table markup separating two cells.
  3. Because the part of the user's signature containing the two exclamation points was wrapped in small tags, and the opening and closing tags are placed in separate table cells, two Linter errors are registered on the page, a missing end tag and a stripped (missing opening) tag.

In the final section of the page, you can see the page as the original poster intended it to appear.

I have seen two exclamation points used in table cells cause this problem in the past, but never in the text of a link. I'm thinking that there is at least one bug here.

Note that in Parsoid, the wikilink is not rendered at all; square brackets are displayed in adjacent cells.

What should have happened instead?:
Two adjacent exclamation points in the rendered-text portion of a wikilink should be rendered as two adjacent exclamation points.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

Event Timeline

Ya, looks like an edge case where the tokenizer needs to give the link a higher priority over "!!" and "||" in a table row .. all the other linter, etc. issues are from this issue in the grammar. I'm going to untag the linter.

Another similar precedence issue is seen on https://om.wikipedia.org/wiki/Template%3AWikipediaTOC?useparsoid=1 where the source has wikitext of this form:

| [[Image:P religion world.svg|25px|Category:Amantii
|left]]

Parsoid breaks that link in the <td> context (whereas it wouldn't outside a table) because the "|" is treated as a table cell marker.

This could potentially be a wontfix and requires editors to fix that wikitext since that is also confusing for editors and requires staring at it a bit. But, if a fix naturally falls out of fixing the precedence issue above, that works out well.

The page at https://en.wikipedia.org/w/index.php?title=User_talk:Nishidani/Index&oldid=1263003121 contains multiple ! characters inside a "display:none" span. They appear to be interpreted as table markup. I don't know if that is a bug, and if so, if it is the same bug as this one. It's something to look at, anyway.

Change #1194795 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/services/parsoid@master] Fix file in table pipe precedence

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

Change #1195059 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/services/parsoid@master] Suppress breaking on !! in wikilinks

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

ABreault-WMF triaged this task as Medium priority.

The page at https://en.wikipedia.org/w/index.php?title=User_talk:Nishidani/Index&oldid=1263003121 contains multiple ! characters inside a "display:none" span. They appear to be interpreted as table markup. I don't know if that is a bug, and if so, if it is the same bug as this one. It's something to look at, anyway.

The wikitext parsers don't consider css layout when parsing so that inline rule to display none wouldn't be expected to have any effect on table parsing

Change #1194795 merged by jenkins-bot:

[mediawiki/services/parsoid@master] Fix file in table pipe precedence

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

Change #1195059 merged by jenkins-bot:

[mediawiki/services/parsoid@master] Suppress breaking on !! in wikilinks

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

Change #1197319 had a related patch set uploaded (by Subramanya Sastry; author: Subramanya Sastry):

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.22.0-a28

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

Change #1197319 merged by jenkins-bot:

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.22.0-a28

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

Item #1 in the initial bug report is not fixed.

https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1310145580&useparsoid=1

still hides the closing /small tag when the code is rendered using syntaxhighlight.

If you remove the !! from the wikilink, neither the opening nor the closing small tags are rendered in the syntaxhighlight block (see the second syntaxhighlight block at https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1322712266&useparsoid=1)

You had said,

(This happens only if you have the "Change UTC-based times and dates, such as those used in signatures, to be relative to local time" gadget enabled in Preferences, so there may be another bug there.)

which is the case.

The issue is probably that the node with the datetime has an escaped html string </small> which is being passed to jQuery unescaped and interpreted as a closing tag, and dropped, when replacing the datetime.

Maybe somewhere around here,
https://en.wikipedia.org/wiki/User:Gary/comments_in_local_time.js#L-438

Perhaps leave a comment on the talk page for the gadget author to address?
https://en.wikipedia.org/wiki/User_talk:Gary/comments_in_local_time.js

There's also a check to skip preformatted text that maybe wants to walk up the tree and not just inspect the parent node, since in this case, the text node with the date is nested in a span, which is nested in a pre tag,
https://en.wikipedia.org/wiki/User:Gary/comments_in_local_time.js#L-416

From a wikitext parsing perspective, I think the task is resolved though

That editor has 66 contributions in the last four years, so I suspect that the WMF might have to take responsibility for that supported gadget. I left a message on the author's talk page on the off chance that they are watching.

Would you be opposed to filing a new phab task and tagging WMF-General-or-Unknown ?

This bug does not appear to be fixed.

This bug was about the precedence of !! in wikilinks and that doesn't seem to be an issue on that page. I see one example,

|-
| Official Knitwits Head Gear Just For You !! || 1 || 19:05, 4 December 2012 || 19:05, 4 December 2012 ||align="right"| <span style="display: none;">{{padleft:0|9|!}}</span> 00:00:00 || [[User talk:Nishidani/Archive 15#Official Knitwits Head Gear Just For You !!]]

but the wiklink renders ok, so I still think this bug is fixed.

See:

https://en.wikipedia.org/w/index.php?title=User_talk:Nishidani/Index&oldid=1263003121&useparsoid=1

Filed as T417792.

As far as I see, the bug there is with this part |align="right"| <span style="display: none;">{{padleft:0|9|!}}</span> 00:00:00 |, which we can address in T417792, thanks for filing it.