Page MenuHomePhabricator

Selfref template produces nested div.hatnote elements, causing duplicate hatnote output in MCS
Closed, ResolvedPublic

Description

Found another bug caused by Template:Selfref as used on Wikimedia Foundation. (Previously: T182349)

The template produces different HTML via different API actions, both containing buggy-looking nested div.hatnote elements (just with the nesting relationship reordered).

Wikitext: {{selfref|{{for|the project page on the foundation itself|:Wikipedia:Wikimedia Foundation}}|hat}}

In MW HTML (and via api.php?action=parse):

<div role="note" class="hatnote navigation-not-searchable">\n
 <div role="note" class="hatnote navigation-not-searchable">
  <span class="plainlinks selfreference noprint">
   For the project page on the foundation itself, see <a href="/wiki/Wikipedia:Wikimedia_Foundation" title="Wikipedia:Wikimedia Foundation">Wikipedia:Wikimedia Foundation</a>.
  </span>
 </div>
</div>

In Parsoid HTML (via api.php?action=expandtemplates):

<div role="note" class="hatnote navigation-not-searchable" about="#mwt1" typeof="mw:Transclusion" data-mw='{"parts":[{"template":{"target":{"wt":"selfref","href":"./Template:Selfref"},"params":{"1":{"wt":"{{for|the project page on the foundation itself|:Wikipedia:Wikimedia Foundation}}"},"2":{"wt":"hat"}},"i":0}}]}' id="mwAg">
 <span class="plainlinks selfreference noprint">
  <div role="note" class="hatnote navigation-not-searchable">
   For the project page on the foundation itself, see <a rel="mw:WikiLink" href="./Wikipedia:Wikimedia_Foundation" title="Wikipedia:Wikimedia Foundation">Wikipedia:Wikimedia Foundation</a>.
  </div>
 </span>
</div>

I noticed this because the duplicate hatnote divs are tripping up MCS when it queries for hatnotes with querySelectorAll('.hatnote'):

hatnotes: [
  "<span class=\"plainlinks selfreference noprint\"><div role=\"note\" class=\"hatnote navigation-not-searchable\">For the project page on the foundation itself, see <a href=\"/wiki/Wikipedia:Wikimedia_Foundation\" title=\"Wikipedia:Wikimedia Foundation\">Wikipedia:Wikimedia Foundation</a>.</div></span>",
  "For the project page on the foundation itself, see <a href=\"/wiki/Wikipedia:Wikimedia_Foundation\" title=\"Wikipedia:Wikimedia Foundation\">Wikipedia:Wikimedia Foundation</a>."
]

(https://en.wikipedia.org/api/rest_v1/page/mobile-sections-lead/Wikimedia_Foundation)

Note: This doesn't affect hatnotes produced with the regular Hatnote template (e.g., on https://en.wikipedia.org/api/rest_v1/page/html/Wikipedia.)

Event Timeline

Mholloway created this task.Feb 8 2018, 9:34 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Try {{selfref|{{for|the project page on the foundation itself|:Wikipedia:Wikimedia Foundation}}|hat}} in the https://en.wikipedia.org/wiki/Wikipedia:Sandbox?action=edit and inspect. I find the output as below.

<div role="note" class="hatnote navigation-not-searchable">
<div role="note" class="hatnote navigation-not-searchable"><span class="plainlinks selfreference noprint">For the project page on the foundation itself, see <a href="/wiki/Wikipedia:Wikimedia_Foundation" title="Wikipedia:Wikimedia Foundation">Wikipedia:Wikimedia Foundation</a>.</span></div>
</div>

Same with https://en.wikipedia.org/w/api.php?action=parse&text={{selfref|{{for|the%20project%20page%20on%20the%20foundation%20itself|:Wikipedia:Wikimedia%20Foundation}}|hat}}&format=jsonfm

However, for some reason, Parsoid gets something else from the API:

[subbu@earth parsoid] echo '{{selfref|{{for|the project page on the foundation itself|:Wikipedia:Wikimedia Foundation}}|hat}}' | parse.js --dump tplsrc
=================================
Template:Selfref
---------------------------------
<div role="note" class="hatnote navigation-not-searchable"><span class="plainlinks selfreference noprint"><div role="note" class="hatnote navigation-not-searchable">For the project page on the foundation itself, see [[:Wikipedia:Wikimedia Foundation]].</div></span></div>

There is still the duplicate wrapper but, the span and div tags have swapped their nesting relationship. To be investigated.

However, the duplicate <div> comes from the API itself.

Mea culpa: I was thrown off by the formatting earlier when viewing the MW HTML and missed the preceding duplicate div. I'll update the description.

Mholloway updated the task description. (Show Details)Feb 9 2018, 4:55 AM
Mholloway renamed this task from Extra inner div.hatnote when parsing selfref template causes duplicate hatnote entries in MCS to Element reordering when parsing selfref template causes duplicate hatnote entries in MCS.Feb 9 2018, 4:58 AM
Mholloway updated the task description. (Show Details)
Mholloway renamed this task from Element reordering when parsing selfref template causes duplicate hatnote entries in MCS to Element reordering when parsing selfref template.Feb 9 2018, 5:04 AM
Mholloway updated the task description. (Show Details)

Updated to reflect that Parsoid isn't causing the MCS problem. It looks like the template itself is misbehaving by creating the duplicate div. Still, maybe worth looking into whether the element reordering is a bug.

https://en.wikipedia.org/w/api.php?action=expandtemplates&text={{selfref|{{for|the%20project%20page%20on%20the%20foundation%20itself|:Wikipedia:Wikimedia%20Foundation}}|hat}} shows that the m/w API is generating that output that Parsoid emits. Not sure why expandtemplates and parse endpoints are doing different things here.

Mholloway renamed this task from Element reordering when parsing selfref template to Selfref template produces nested div.hatnote elements.Feb 9 2018, 2:18 PM
Mholloway updated the task description. (Show Details)
Mholloway updated the task description. (Show Details)
Mholloway updated the task description. (Show Details)Feb 9 2018, 2:23 PM
Mholloway updated the task description. (Show Details)
Mholloway renamed this task from Selfref template produces nested div.hatnote elements to Selfref template produces nested div.hatnote elements, causing duplicate hatnote output in MCS.Feb 9 2018, 5:59 PM
Mholloway closed this task as Resolved.Jun 27 2018, 6:06 PM
Mholloway claimed this task.