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

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

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 https://en.wikisource.org/wiki/Ponsonby,_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

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

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

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

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

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

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 With the change I have noticed that the css class "indented-page" is now quirked

https://en.wikisource.org/wiki/1911_Encyclop%C3%A6dia_Britannica/Nukha

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.

In T255073#6213215, @Billinghurst wrote:

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>
</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.