Page MenuHomePhabricator

Different parsing behaviour for images inside and outside tables
Closed, DeclinedPublicBUG REPORT

Description

Steps to replicate the issue:

What happens?

In table
<span class="flagicon">
  <span class="mw-default-size" typeof="mw:File">
    <a href="..." class="mw-file-description" title="23x20px link=">
      <img alt="23x20px link=" src="..." decoding="async" width="727" height="750" class="mw-file-element" srcset="..." data-file-width="727" data-file-height="750" />
    </a>
  </span>
  &#160;
</span>

What should have happened instead?

Normal
<span class="flagicon">
  <span typeof="mw:File">
    <span>
      <img alt="" src="..." decoding="async" width="19" height="20" class="mw-file-element" srcset="..." data-file-width="727" data-file-height="750" />
    </span>
  </span>
  &#160;
</span>

Notice the following parts:

  • title="23x20px link="
  • alt="23x20px link="

I don't recall ever seeing something like this. Has the parser been (re)touched recently?

Event Timeline

Arlolra subscribed.

The crucial piece you're tripping on here is || in the file link [[Tập tin:Hellenic Army War Flag.svg|23x20px||alt=|link=]]

{|
| test || 123
|}

parses as,

<table>
<tbody><tr>
<td>test</td>
<td>123
</td></tr></tbody></table>

Table syntax has higher precedence than the file link, in the legacy parser.

So, for the example,

{|
| '''<span class="flagicon">[[File:Test.jpg|23x20px||link=]]&nbsp;</span>[[Lục quân Hy Lạp]]'''
|}

an intermediary step in the parser will yield,

<table>
<tr>
<td>'''<span class="flagicon">[[File:Test.jpg|23x20px</td>
<td>link=]]&nbsp;</span>[[Lục quân Hy Lạp]]'''
</td></tr></table>

The file caption then becomes 23x20px</td>\n<td>link=, which gets reduced to 23x20px link=.

Parsoid, for its part, gives the file link higher precedence,

<table>
<tbody><tr><td><b><span class="flagicon"><span typeof="mw:File" data-mw='{"caption":""}'><span><img resource="./File:Test.jpg" src="//upload.wikimedia.org/wikipedia/commons/thumb/2/28/JPG_Test.jpg/23px-JPG_Test.jpg" decoding="async" data-file-width="350" data-file-height="210" data-file-type="bitmap" height="14" width="23" class="mw-file-element" /></span></span><span typeof="mw:Entity"> </span></span><a rel="mw:WikiLink" href="./Lục_quân_Hy_Lạp" title="Lục quân Hy Lạp">Lục quân Hy Lạp</a></b></td></tr>
</tbody></table>

Table syntax has higher precedence than the file link, in the legacy parser.

Parsoid, for its part, gives the file link higher precedence

@Arlolra I'm confused. What do you mean by "the legacy parser"? A previous version of Parsoid? Then what is "Parsoid" in the latter example?

If "the legacy parser" gives higher precedence to table syntax, how come this worked correctly before and not now?

Sorry, there are two wikitext parsers in MediaWiki. The "legacy parser" is the one that still produces what you'd see in a desktop browser.

Parsoid is a newer library that produces the output for VisualEditor, the mobile applications, and so forth.

If "the legacy parser" gives higher precedence to table syntax, how come this worked correctly before and not now?

I'm assuming what happened is this template was recently edited,
https://vi.wikipedia.org/w/index.php?title=B%E1%BA%A3n_m%E1%BA%ABu:Country_data_Hy_L%E1%BA%A1p&action=history

which affected the output of |{{{border-{{{variant}}}|{{{border|border}}}}}}| from
https://vi.wikipedia.org/w/index.php?title=B%E1%BA%A3n_m%E1%BA%ABu:Bi%E1%BB%83u_t%C6%B0%E1%BB%A3ng_l%C3%A1_c%E1%BB%9D/core&action=edit

That could result in the empty file option || which would break the parsing in a table cell position.

So if I were to write the following some time ago I would also get a broken result?

{|
| [[File:Foo.jpg||alt=Lorem ipsum]]
|}

That makes sense at the same time it doesn't. Is this a NOFIX then?

So if I were to write the following some time ago I would also get a broken result?

Yes, I believe so. I checked as far back as some MediaWiki installations in the 1.3X series and that was the case.

That makes sense at the same time it doesn't. Is this a NOFIX then?

I don't think it will be fixed in the "legacy parser" but the good news is that Parsoid parses that snippet the way you're expecting and will hopefully be the de facto wikitext parser for desktop views in the future.