When you view the source of any page (e.g. https://www.mediawiki.org/wiki/MediaWiki), 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.
This certainly has potential to break lots of tools, gadgets, user scripts etc. when wmf.36 hits the wikipedias tomorrow.
@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).
@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.
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.
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: https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/Vector/+/597133/15/includes/SkinVector.php 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.