Page MenuHomePhabricator

Duplicate <div id="mw-content-text" ...> in Vector HTML output
Closed, ResolvedPublic


When you view the source of any page (e.g., the wrapper element <div id="mw-content-text" lang="en" dir="ltr" class="mw-content-ltr"> appears twice. This is invalid HTML (since IDs must be unique) and may break things in funny ways.

Event Timeline

matmarex renamed this task from Duplicate <div id="mw-content-text" lang="en" dir="ltr" class="mw-content-ltr"> in Vector HTML output to Duplicate <div id="mw-content-text" ...> in Vector HTML output.Jun 10 2020, 7:57 PM
matmarex added subscribers: Jdlrobson, Niedzielski.

This has broken things in awkward ways on English Wikisource (project-local javascript relies on only one such element existing). I've confirmed the same happens on Commons (Main Page). I've been told it only happens in Vector (but haven't verified yet).

This certainly has potential to break lots of tools, gadgets, user scripts etc. when wmf.36 hits the wikipedias tomorrow.

Change 604504 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] Don't modify OutputPage value

Yuck looks like SkinTemplate in core modifies the OutputPage directly which is not necessary:

$out->mBodytext = $this->wrapHTML( $title, $out->mBodytext );

@Jdlrobson Any chance of a SWAT deploy on this?

It looks like we can work around this on enWS, but it'd be fiddly and we don't really have local interface-admins. I don't know how many (if any) other Wikisourcen are actually affected, but it might be nonzero due to sharing of code between the projects. The failure mode is mostly cosmetic, but kinda "in your face"; e.g. the whole header block and main navigation gets duplicated on,_Henry_(DNB00) (and all other mainspace pages on the project).

@Xover of course but first I need somebody to review my change :)

Change 604520 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@wmf/1.35.0-wmf.36] Don't modify OutputPage value

Change 604504 merged by jenkins-bot:
[mediawiki/core@master] Don't modify OutputPage value

Change 604520 merged by jenkins-bot:
[mediawiki/core@wmf/1.35.0-wmf.36] Don't modify OutputPage value

Mentioned in SAL (#wikimedia-operations) [2020-06-10T23:55:54Z] <catrope@deploy1001> Synchronized php-1.35.0-wmf.36/includes/skins/SkinTemplate.php: T255073 (duration: 01m 07s)

This should be fixed. Impacted pages will need to be purged either via an edit or action=purge. I'll write up why this happened in detail tomorrow.

Jdlrobson lowered the priority of this task from Unbreak Now! to Medium.Jun 10 2020, 11:57 PM

@Jdlrobson With the change I have noticed that the css class "indented-page" is now quirked

it now produces as text

‹div class="indented-page">NUKHA, a town

I cannot say whether that was a global css statement or local. Either way, I didn't know think it should have display like that.

I cannot say whether that was a global css statement or local. Either way, I didn't know think it should have display like that.

s:1911 Encyclopædia Britannica/Nukha looks fine to me currently. Could it be that the page just hadn't been purged yet?

The style for .indented-page for non-Proofread Page pages lives in s:MediaWiki:Gadget-enws-tweaks.css (line 94–96), and the class is then forcibly removed by s:MediaWiki:PageNumbers.js (line 173–178) on any page where there is a table.pr_quality (i.e. on pages where Proofread Page's <pages … /> tag is used to transclude content from the Page: namespace).

PageNumbers.js is broken in that if an element has .indented-page set, PageNumbers.js will remove all classes from that element (not just .indented-page), but that's the case irrespective of this current bug.

However, between the duplication of #mw-content-text, which led to this code being output:

<div id="mw-content-text">
  <div id="mw-content-text"></div>

…and our local various and sundry styles and scripts, I would be very surprised if we didn't see certain knock-on problems, like wonky margins and misplaced text.

Keep in mind that PageNumbers.js wraps #mw-content-text in three new divs (div.pageContainer, div.regionContainer, div.columnContainer), and that this bug made the script clone those so they appeared twice, and it then tries to do other manipulations on those new divs, including messing with margins etc. And it does this on every single page regardless of whether ProofreadPage is in play: it hides the toolbar functions for dynamic layouts on pages where it is not supposed to be active, but it still does all the DOM manipulations on every single page (cough). It is fragile when this sort of change happens (and these kinds of changes need not be bugs; they can happen as a result of deliberate choices too), is what I'm saying.

Jdlrobson claimed this task.

Just to explain what happened here:

Vector is currently in a transitionary state moving away from using BaseTemplate. It has been in this state for a bit longer than expected due to some extension migrations taking a bit longer than expected.

A change relating to the migration: duplicated code in SkinTemplate however overlooked the fact that SkinTemplate modifies the OutputPage object ( for no good reason) inside the prepareQuickTemplate since 2012, (prior to gerrit days: 3b32851a94207e5f1903d0db047c4ab4f775e617). The result was the wrap function was called twice. The fix above has removed this side effect.

In terms of protecting this on the long term, I don't see any other unexpected side effects in SkinTemplate so there should be no risk of this happening again.
SkinTemplateOutputPageBeforeExec can potentially have side effects and that is scheduled for deprecation => T60137.