| • bmansurov | |
| Aug 15 2016, 11:03 PM |
| F4368436: Screen Shot 2016-08-16 at 2.41.10 PM.png | |
| Aug 16 2016, 10:05 PM |
| F4365730: Screen Shot 2016-08-15 at 18.56.04.png | |
| Aug 15 2016, 11:03 PM |
| F4365732: Screen Shot 2016-08-15 at 19.02.41.png | |
| Aug 15 2016, 11:03 PM |
Happens in Chrome 51.0.2704.84 (64-bit) / Mac OS X 10.11.6 (15G31).
It happens in the JS version of the menu too:
To reproduce go to https://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page and click on the hamburger icon.
The regression hasn't hit production yet. Here is a screenshot from https://en.m.wikipedia.org/wiki/Book
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • mmodell | T140971 MW-1.28.0-wmf.15 deployment blockers | |||
| Resolved | Krinkle | T143066 ResourceLoader 'target' filter not applied to "exempt" modules |
@MBinder_WMF, yes the team has reviewed this. We didn't have a chance to estimate it though.
@bmansurov OK, if you're confident that there is a shared understanding of the task, and the team has evaluated it for potential hidden risk, please feel free to put a number on it.
I'm a bit worried about this so I've switched focus here... more information to follow.
It looks like the content of MediaWiki:Common.css is now being load on mobile and MediaWiki:Mobile.css is being ignored as of T87871 and this change. According to grafana, as a result of this on the beta cluster, I'm seeing a 6kb increase in the bytes of css we shift to users since 14th August for no obvious benefit.
Given this css is top loaded, this is likely to lead to a negative impact on first paint for all mobile users as so I'm slapping an unbreak now and making this a deployment blocker pending further investigation.
cc @ori @Krinkle @Catrope @greg
Plan of action? wmf.15 is only on testwikis right now. I assume we'll keep that and deploy a fix to wmf.15 asap before rolling further?
Reverting at this point would cost a lot more than simply updating MobileFrontend to play along with the new restriction. I'll check it out today.
Change 305147 had a related patch set uploaded (by Krinkle):
OutputPage: Apply target and origin filter to exempt modules
No change needed in MobileFrontend actually. During the separation between OutputPage handling and ResourceLoader queue formatting, the filter was kept in OutputPage. This fixed several bugs, but meant that a handful of exempt modules (specifically, startup, site.styles and user.styles) were no longer subject to target filtering.
The end result is that, for these two unrelated reasons, Common.css got loaded and Mobile.css did not.
Fixed in https://gerrit.wikimedia.org/r/305147.
Change 305147 merged by jenkins-bot:
OutputPage: Apply target and origin filter to exempt modules
Change 305153 had a related patch set uploaded (by Jdlrobson):
OutputPage: Apply target and origin filter to exempt modules
Change 305153 merged by jenkins-bot:
OutputPage: Apply target and origin filter to exempt modules