Page MenuHomePhabricator

[regression] Minerva: Cached HTML are not getting the responsive infobox styles
Closed, ResolvedPublicBUG REPORT

Description

NOTE: This impacts < 50,000 page views an hour. If experiencing this issue run ?action=purge on the appropriate page to address the issue.

Steps to replicate the issue (include links if applicable):

What happens?:
The infoboxes don't get expanded to full viewport size because since T361589, they get the styling from WikimediaMessages instead of the old template hacks which relies on body.skin--responsive. body.skin--responsive is not activated by default.

What should have happened instead?:
responsive styles should have been applied to the infobox.

Other information (browser name/version, screenshots, etc.):
On the other hand, if a user has responsive skin mode activated, they now always get the full-size infobox independently from the current viewport.

Event Timeline

It is working correctly for me. Could you check something for me?

Is it possible you disabled the preference for a responsive skin on Special:Preferences? This box should be ticked by default.

Screenshot_20240417_064946_Chrome.jpg (2×1 px, 618 KB)

Oh you said logged out.. even weirder then. Mmm

which relies on body.skin--responsive. body.skin--responsive is not activated by default.

Am I misunderstanding this statement?

Screenshot 2024-04-17 at 6.53.54 AM.png (1×2 px, 391 KB)

This is what I'm seeing:

Screenshot 2024-04-17 at 6.54.49 AM.png (1×1 px, 269 KB)

Seems like the cache got me, now I'm seeing the correct styling, too. At first I checked with disabling/enabling the responsive skin option and saw the difference after doing that, so I thought anons don't have the responsive mode activated by default and didn't check the presence of the class. Sorry for inconvenience.

The problem with the fullsize-expanded infoboxes on wide viewports stays, though. Not sure if it should be like that, but if not it should probably be a different task.

Seems like the cache got me, now I'm seeing the correct styling, too. At first I checked with disabling/enabling the responsive skin option and saw the difference after doing that, so I thought anons don't have the responsive mode activated by default and didn't check the presence of the class. Sorry for inconvenience.

No problem just happy to learn that's working as expected! I understand what happened here now - we switched to a new module, but that module was not in cache so wasn't being applied. I'll look into this more today to get a sense of impact and see if we need an additional fix for that.

The problem with the fullsize-expanded infoboxes on wide viewports stays, though. Not sure if it should be like that, but if not it should probably be a different task.

Yep thanks for flagging! I'm fixing that today in next available backport window: https://gerrit.wikimedia.org/r/c/1020736/

Jdlrobson renamed this task from Minerva: logged-out readers and users that don't have responsive skin mode activated don't get the responsive infobox styles to [regression] Minerva: Cached HTML are not getting the responsive infobox styles.Apr 17 2024, 3:45 PM
Jdlrobson claimed this task.
Jdlrobson triaged this task as High priority.
Jdlrobson added a project: Regression.

I experienced this while trying to do the work on making a common site styles module in Russian Wikipedia.

I moved the styles into the gadget and soon discovered that, for whatever reason, cached views on mobile version do not get updated CSS:
https://ru.wikipedia.org/w/index.php?title=MediaWiki:Mobile.css&action=history

I had to move the stuff back into asynchronous CSS (Mobile.css) page because the asynchronous CSS gets updated but synchronous CSS doesn’t.

I think this is primarily what causes these issues: cached views for IP readers on mobile website only get CSS updates if the page itself gets updated (via edit etc.). Otherwise mobile version gets stale CSS for a week and more. Whatever is done with caching in the mobile version should be fixed because this is going to be more and more of an issue the more actual CSS capabilities of the mobile version improve (currently Mobile.css is an asynchronously loaded file).

P.S.: my comment is prompted by seeing this anonymously in English Wikipedia right now:

image.png (940×1 px, 257 KB)

Change #1021518 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[operations/mediawiki-config@master] Temporarily restore wgMinervaApplyKnownTemplateHacks for cached HTML

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

While this bug is the most apparent, it would be also good to explore in general what causes this problem in Minerva / mobile version in particular. I don't think the expectation of a style change should be any different on Minerva than it is on other skins. If an update is done, it should be properly propagated no matter the skin. Currently that is only the case with async CSS loaded by MobileFrontend’s JS.

This problem happens because the styles were moved to a new ResourceLoader module (ext.wikimediamessages.styles), which was not loaded on these pages before. Styles are loaded using <link> tags present in the generated page HTML, which is cached for logged-out users, and so it will be missing on some pages for up to 14 days (https://wikitech.wikimedia.org/wiki/CDN#Retention). The actual CSS that is served by /w/load.php?...&modules=ext.wikimediamessages.styles correctly includes them, but that file is not loaded on these pages.

To avoid this problem in the future, new modules must be added (with empty content) some time in advance, or the old CSS has to be kept in the old modules for some time.

For example, this is what I'm seeing at https://en.m.wikipedia.org/wiki/Mairi_Campbell (just a random page) while logged out:

image.png (2×3 px, 389 KB)

This is the HTML I get served, note how it has no mention of "wikimediamessages" at all:


@stjn I am not sure if the problem you're describing is the same. It's less obvious what could have happened there, but in your case it could actually be outdated CSS, either cached by your browser or somewhere server-side.

It's easily explained. CSS and HTML have different cache times.

We disabled the loading of these styles in Minerva and added a new ResourceLoader module in the HTML via WikimediaMessages
CSS cache is 5 minutes so old styles disappeared promptly.
HTML cache can be a few days so we are left in the situation where some pages have updated CSS but not updated HTML.

This is no different from other skins and we see similar bugs in desktop all the time - but generally they get noticed and addressed quicker because more eyes are on it.

@stjn I am not sure if the problem you're describing is the same. It's less obvious what could have happened there, but in your case it could actually be outdated CSS, either cached by your browser or somewhere server-side.

I think in that case it was also what you described: new module not propagating to the HTML. It wasn’t browser-side cache because I also checked it without any cache in Firefox Focus etc. But, to be frank, I don’t think it is the same in the desktop version: I use Wikipedia anonymously extensively and I’ve both added and removed gadgets before and the change propagation on desktop is not the same as it is on mobile. I don’t exactly know the reason for it, but it doesn’t take week or two to add a new gadget module to desktop views, for instance. If anything, the changes in default modules get reflected on pages much quicker than it was with Minerva.

Desktop and mobile have different parser caches.

Desktop and mobile have different parser caches.

They don't any more. If you compare e.g. https://en.wikipedia.org/wiki/Mairi_Campbell and https://en.m.wikipedia.org/wiki/Mairi_Campbell, they both have the same parser cache key, as shown in the HTML comment on the page (right now, I see "Saved in parser cache with key enwiki:pcache:idhash:25315058-0!canonical and timestamp 20240413070106 and revision id 1213030049").

As far as I can tell this was changed in a11bbb9fb2fee98e81ba13ce9ec2821ab8a85ad5 a while ago.

They certainly have other differences though.

Ah that's good to know.. but varnish cache is still different, right?

Change #1021518 merged by jenkins-bot:

[operations/mediawiki-config@master] Temporarily restore wgMinervaApplyKnownTemplateHacks for cached HTML

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

Mentioned in SAL (#wikimedia-operations) [2024-04-18T20:25:17Z] <cjming@deploy1002> Started scap: Backport for [[gerrit:1021518|Temporarily restore wgMinervaApplyKnownTemplateHacks for cached HTML (T362747)]]

Mentioned in SAL (#wikimedia-operations) [2024-04-18T20:27:45Z] <cjming@deploy1002> jdlrobson and cjming: Backport for [[gerrit:1021518|Temporarily restore wgMinervaApplyKnownTemplateHacks for cached HTML (T362747)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-04-18T20:42:32Z] <cjming@deploy1002> Finished scap: Backport for [[gerrit:1021518|Temporarily restore wgMinervaApplyKnownTemplateHacks for cached HTML (T362747)]] (duration: 17m 14s)

Fixed. This will be undone as part of T362727