Mobile.js/Mobile.css not loading after upgrading to MediaWiki 1.35
Closed, DuplicatePublicBUG REPORT
Actions

Description

Prior to MediaWiki 1.35 we have not had this issue. For over a month now I have been trying to find a solution to this, to no avail. One of our users originally reported an issue where Mobile.js/Mobile.css was not loading (original Miraheze task). After doing extensive debugging I am no closer to finding the problem, so here is what I do know so far:

Mobile.css/Mobile.js seems to work on https://test3.miraheze.org even though the setup and extension version of both Minerva and MobileFrontend is the exact same.
Minerva.js does load. Minerva.css does not load. Neither Mobile.js or Mobile.css ever loads.
On our downstream task you can see additional debugging that was done.

Related Objects

Mentioned Here: T190083: Make MediaWiki:Mobile.css render-blocking
T270603: Module site.styles generates different output depending on mobile cookie, if $wgMFSiteStylesRenderBlocking = true;

Event Timeline

Universal_Omega created this task.Dec 27 2020, 8:54 AM

Restricted Application added subscribers: Masumrezarock100, Aklapper. · View Herald TranscriptDec 27 2020, 8:54 AM

Universal_Omega moved this task from Radar to Miraheze-Linked on the User-RhinosF1 board.Dec 27 2020, 8:54 AM

edwardspec subscribed.Dec 27 2020, 3:22 PM

Universal_Omega updated the task description. (Show Details)Dec 27 2020, 3:32 PM

Patch Demo showing Mobile.css works in MW 1.35 with common extensions: https://patchdemo.wmflabs.org/wikis/233b6267f4e0cb50234d1bbf7bac0983/w/index.php/MediaWiki:Mobile.css?useformat=mobile

Strangely I only sometimes see a blue background as expected. Trying in a different browser/session, I generally do not see it. It seems there's some weirdness going on with the conditions under which Mobile.css is served.

My wild guess is there are missing commits in the MW1_35 branch for either MobileFrontend and/or Minerva.

Probably the same as T270603 ?

Jdlrobson added a project: MediaWiki-ResourceLoader.Jan 4 2021, 8:32 PM

Restricted Application added a project: Performance-Team. · View Herald TranscriptJan 4 2021, 8:32 PM

Jdlrobson added a project: Reading-Web-Third-Party-Support.Jan 4 2021, 9:19 PM

Assumed duplicate of T270603. Marking as stalled pending confirmation by @Universal_Omega that 1) they use MobileFrontend without separate domain and 2) that it is indeed a caching issue, confirm by e.g. checking the load.php response of the mobile.js code and see that it works if you add a cache buster the the URL.

In T270845#6737377, @Krinkle wrote:

Assumed duplicate of T270603. Marking as stalled pending confirmation by @Universal_Omega that 1) they use MobileFrontend without separate domain and 2) that it is indeed a caching issue, confirm by e.g. checking the load.php response of the mobile.js code and see that it works if you add a cache buster the the URL.

I think the comment at T270845#6719605 is in regards my comment at T270845#6718192 about inconsistencies on Patch Demo. The bug reported here I'm fairly sure is not the same as T270603. I'm not even sure if the issue observed on Patch Demo is the same, but it does sound similar.

Despite the inconsistent behaviour, I am able to at least get Mobile.js/Mobile.css to work on Patch Demo. This is not the case for https://spcodex.wiki and some other Miraheze wikis since the MW 1.35 upgrade. The issue we're seeing there is that Common.js and Minerva.js load for mobile users, but Common.css, Minerva.css and Mobile.js/Mobile.css do not (a situation that seems to be different from T270603). These wikis do not use a separate domain for MobileFrontend, and $wgMWSiteStylesRenderBlocking appears to be the default value (false).

I have not personally observed the same issue on any non-Miraheze wiki, but Universal_Omega said others have, which led us to believe there was a larger issue with these extensions and/or MW 1.35.

In T270845#6737377, @Krinkle wrote:

Assumed duplicate of T270603. Marking as stalled pending confirmation by @Universal_Omega that 1) they use MobileFrontend without separate domain and 2) that it is indeed a caching issue, confirm by e.g. checking the load.php response of the mobile.js code and see that it works if you add a cache buster the the URL.

I can confirm:

we don't use a separate domain for MF
it does appear it could likely be a cache issue (without actually checking this, yet) - because it works on test3.miraheze.org but not on any other Miraheze wiki, and our cache setup is a little different on our test wiki, and that would be one of the only things that makes sense why.

Krinkle removed a project: MediaWiki-ResourceLoader.Jan 19 2021, 9:37 PM

Jdlrobson moved this task from Needs triage to MobileFrontend specific on the Mobile board.Feb 4 2021, 1:41 AM

Krinkle moved this task from Limbo to Watching on the Performance-Team (Radar) board.Mar 15 2021, 8:04 PM

R4356th subscribed.Apr 4 2021, 6:24 PM

Universal_Omega changed the task status from Stalled to Open.Apr 5 2021, 10:44 PM

This seems to now work again.

Maintenance_bot moved this task from Miraheze-Linked to Done on the User-RhinosF1 board.Apr 5 2021, 11:15 PM

In T270845#6974458, @Universal_Omega wrote:

This seems to now work again.

It's not over at https://spcodex.wiki/wiki/MediaWiki:Mobile.css?useformat=mobile. The page title should have the same font as you see on desktop. Another example is https://socdemwiki.miraheze.org/w/index.php?title=MediaWiki:Mobile.css&useformat=mobile, where .mw-body should have a background color of #333, but this CSS rule is not being applied.

In T270845#6974559, @MusikAnimal wrote:

In T270845#6974458, @Universal_Omega wrote:

This seems to now work again.

It's not over at https://spcodex.wiki/wiki/MediaWiki:Mobile.css?useformat=mobile. The page title should have the same font as you see on desktop. Another example is https://socdemwiki.miraheze.org/w/index.php?title=MediaWiki:Mobile.css&useformat=mobile, where .mw-body should have a background color of #333, but this CSS rule is not being applied.

Oh, my bad then. I guess I tested wrong.

@Universal_Omega No worries. I'll re-open assuming this is still an upstream issue, which was the conclusion we came to.

Any chance you could confirm this is related to caching on Miraheze's end, as Krinkle mentioned at T270845#6737377? I'm happy to help too if there's a simple way for me to bypass Varnish (or whichever cache we suspect is the culprit). If it is, then perhaps this indeed is a duplicate of T270603.

In T270845#6974657, @MusikAnimal wrote:

@Universal_Omega No worries. I'll re-open assuming this is still an upstream issue, which was the conclusion we came to.

Any chance you could confirm this is related to caching on Miraheze's end, as Krinkle mentioned at T270845#6737377? I'm happy to help too if there's a simple way for me to bypass Varnish (or whichever cache we suspect is the culprit). If it is, then perhaps this indeed is a duplicate of T270603.

Unfortunately I can't confirm if it's caching on Miraheze's end as I am no longer a system administrator and therefore no longer have access to run tests on that. CC @Paladox / @Reception123 to run that tests and confirm whether or not it's cache related.

Universal_Omega moved this task from Done to Miraheze-Linked on the User-RhinosF1 board.Apr 14 2021, 6:13 PM

Universal_Omega updated the task description. (Show Details)Apr 15 2021, 12:45 AM

@Krinkle this does not appear to be a caching issue.

Krinkle added a comment.Apr 21 2021, 10:28 PM

This comment was removed by Krinkle.

@MusikAnimal wrote at https://phabricator.miraheze.org/T6362#129249

Issue still stands at spcodex.wiki and possibly the other wikis mentioned here, at least https://mcspringfieldserver.miraheze.org/wiki/MediaWiki:Mobile.css?useformat=mobile (font-size: 0.8em is not present on the <body> of that page as it should be).

What I've observed so far:

SpecialVersion:

MediaWiki 1.35.2 at miraheze/mediawiki@48b55a1 (commit log: some patches ahead of REL1_35).
extensions/MobileFrontend at 1421405 (commit log: REL1_35).
skins/Minerva at 4f16566 (commit log: REL1_35).

View source of https://mcspringfieldserver.miraheze.org/wiki/MediaWiki:Mobile.css?useformat=mobile

state "site.styles":"ready". This means the module is queued for loading as link rel=stylesheet (as is normal).
The module is not actually in the rel=stylesheet URL. This usually means the module was found to be empty when MW inspected it, where empty means that none of the pages referred to by the module definition exist yet on the current wiki. (Existing as empty page is fine). This is strange of course since we're looking at MediaWiki:Mobile.css and it does exist.

The definition comes from this hook in MobileFrontend@REL1_35. Inclusion of MediaWiki:Mobile.css, however, is conditional on wgMFSiteStylesRenderBlocking which is false by default. (ref T190083). When wgMFSiteStylesRenderBlocking is false, this stylesheet instead loads after the initial browser rendering, through the site module, which is also ships MediaWiki:Common.js or MediaWiki:Mobile.js.

Inspecting the network, we see this load.php request for modules=site (URL reduced to just this module), which does not contain any stylesheets. Sometimes this means the pages exists but have only comments or whitespace that is trimmed away by the minifier. When adding …&debug=true&only=styles however, it is still an empty response. When adding …&useformat=mobile it starts to work.

My conclusion is that this is the same issue as T270603. I think you might be right that it isn't solely caused by caching in your case, but the root cause and needed solution is nonetheless identical to T270603.

In your current configuration there is no way for MobileFrontend to know, when it is modifying the site and site.styles module responses, that this is a request from a page view with useformat=mobile vs one without. The URLs are identical. This information would need to be stored in a cookie so that other requests carry it as well, and then you need to make sure the cache varies cleanly on that cookie (whilst stripping and ignoring all other cookies, to keep allowing optimal CDN caching of load.php for logged-in users, like WMF does). Alternatively, you could use a separate domain which is effectively just a really complicated way of transferring this cookie by proxy of the client following a redirect to a different domain name and then making the request with that domain name attached to the request URL (instead of a cookie attached to the URL).

ResourceLoader requires responses to only vary by wiki, skin and language. What MobileFrontend currently does with this is unsupported, but happens to work when you have a cookie to split the cache, and then in an extension hook bypass RLContext to try to read the cookie, hoping that the CDN layer will take care of making sure to keep the responses cached separately instead of cross-poisoning with other requests that don't cary the cookie.

In T270845#7026569, @Krinkle wrote:

@MusikAnimal wrote at https://phabricator.miraheze.org/T6362#129249

Issue still stands at spcodex.wiki and possibly the other wikis mentioned here, at least https://mcspringfieldserver.miraheze.org/wiki/MediaWiki:Mobile.css?useformat=mobile (font-size: 0.8em is not present on the <body> of that page as it should be).

What I've observed so far:

SpecialVersion:

MediaWiki 1.35.2 at miraheze/mediawiki@48b55a1 (commit log: some patches ahead of REL1_35).

extensions/MobileFrontend at 1421405 (commit log: REL1_35).

skins/Minerva at 4f16566 (commit log: REL1_35).

View source of https://mcspringfieldserver.miraheze.org/wiki/MediaWiki:Mobile.css?useformat=mobile

state "site.styles":"ready". This means the module is queued for loading as link rel=stylesheet (as is normal).

The module is not actually in the rel=stylesheet URL. This usually means the module was found to be empty when MW inspected it, where empty means that none of the pages referred to by the module definition exist yet on the current wiki. (Existing as empty page is fine). This is strange of course since we're looking at MediaWiki:Mobile.css and it does exist.

The definition comes from this hook in MobileFrontend@REL1_35. Inclusion of MediaWiki:Mobile.css, however, is conditional on wgMFSiteStylesRenderBlocking which is false by default. (ref T190083). When wgMFSiteStylesRenderBlocking is false, this stylesheet instead loads after the initial browser rendering, through the site module, which is also ships MediaWiki:Common.js or MediaWiki:Mobile.js.

Inspecting the network, we see this load.php request for modules=site (URL reduced to just this module), which does not contain any stylesheets. Sometimes this means the pages exists but have only comments or whitespace that is trimmed away by the minifier. When adding …&debug=true&only=styles however, it is still an empty response. When adding …&useformat=mobile it starts to work.

My conclusion is that this is the same issue as T270603. I think you might be right that it isn't solely caused by caching in your case, but the root cause and needed solution is nonetheless identical to T270603.

In your current configuration there is no way for MobileFrontend to know, when it is modifying the site and site.styles module responses, that this is a request from a page view with useformat=mobile vs one without. The URLs are identical. This information would need to be stored in a cookie so that other requests carry it as well, and then you need to make sure the cache varies cleanly on that cookie (whilst stripping and ignoring all other cookies, to keep allowing optimal CDN caching of load.php for logged-in users, like WMF does). Alternatively, you could use a separate domain which is effectively just a really complicated way of transferring this cookie by proxy of the client following a redirect to a different domain name and then making the request with that domain name attached to the request URL (instead of a cookie attached to the URL).

ResourceLoader requires responses to only vary by wiki, skin and language. What MobileFrontend currently does with this is unsupported, but happens to work when you have a cookie to split the cache, and then in an extension hook bypass RLContext to try to read the cookie, hoping that the CDN layer will take care of making sure to keep the responses cached separately instead of cross-poisoning with other requests that don't cary the cookie.

@Krinkle Thank you for looking into this. I've closed this as a duplicate of the other task you mentioned.

Winston_Sung subscribed.Sep 2 2021, 4:57 PM

Aklapper edited projects, added affects-Miraheze; removed User-RhinosF1.Aug 15 2022, 1:19 PM

Mobile.js/Mobile.css not loading after upgrading to MediaWiki 1.35Closed, DuplicatePublicBUG REPORTActions

Description

Related Objects

Event Timeline

Mobile.js/Mobile.css not loading after upgrading to MediaWiki 1.35
Closed, DuplicatePublicBUG REPORT
Actions