I remember noticing this while working on T237050 but it doesn't look like i documented not addressing this. As I recall this was a little challenging to get working and given the primary use of the useformat query string parameter is for development. I'm not sure if the issue lies in the hook in ResourceLoader and the targets system or MobileFrontend.

Could you talk a bit about your use case here and the problem you are running into? useformat should not really be used for anything other than development debugging.

When using 'useformat=mobile' on desktop, $ctx->shouldDisplayMobileView() ends up returning false within the ResourceLoaderSiteStylesModulePages/ResourceLoaderSiteModulePages hooks since the 'useformat' query string parameter is unable to be read at the time the hook is run. As a result, the desktop CSS/JS is still used and the mobile CSS/JS is not loaded in.

As far as I know, there is no timing aspect to these hooks in relation to reading query parameters. I suspect it isn't about that, but rather might be a caching issue or a logic problem higher in the stack, e.g. maybe target=mobile isn't set on these URLs?

Untagging from RL for now since useformat isn't an RL feature. This is a MobileFrontend query parameter used for index.php HTML responses. It is never part of load.php or RL Context (in general, not just in the scenario described).

If target=mobile is set, this is forwarded internally within RL. If target isn't set, then that's a skin-level, MF, or otherr extension issue.

This bug also appears on English Wikipedia.

• https://en.m.wikipedia.org/wiki/Template:Update
• https://en.wikipedia.org/wiki/Template:Update?useformat=mobile (View it on your PC, not your mobile device. Do not change user-agent with devtools etc. For mobile devices, you will be redirected to the mobile page.)

If you look closely at https://en.wikipedia.org/wiki/Template:Update?useformat=mobile (View it on your PC, not your mobile device. Do not change user-agent with devtools etc. For mobile devices, you will be redirected to the mobile page.), some parts look different compared to https://en.m.wikipedia.org/wiki/Template:Update. This is a problem caused by loading https://en.wikipedia.org/wiki/MediaWiki:Mobile.css, and in the case of the above page, the code below could not be loaded.

/* The message body cell(s), such as for {{Commonscat}}.
 * this is a very small subset of the styles from Common.css
 * just to make sure the box isn't squashed without any spacing
 * which looks out of place with visuals of other nearby elements
 */
.mbox-text {
	/* @noflip */
	padding: 0.25em 0.9em;
}

This bug also appears on English Wikipedia.

Sure, but the only way you can get to that URL is you manually create it. If you are seeing that URL being linked to in production, please update it or raise a bug as that should be happening.

I think this bug is what I've encountered on MW 1.38.2 and Extension:MobileFrontend 2.4.0 (a test version of the wiki linked below). These results could be replicated by adding on each possible stylesheet on the wiki a formatting rule, such as

.css-vector { font-weight: bold; color: fuchsia; }

and on each possible script a rule to add an element with the class added above, e.g.

$('body').prepend('<span style="background-color:#BBB;" class="css-vector">VECTOR</span>');

I've drawn up a set of tables documenting the current results - https://wiki.guildwars2.com/wiki/User:Chieftain_Alex/MediaWiki#CSS_and_JS . The top table is the native result. The middle table is the ideal. You can ignore the bottom table which is the result of my workaround.

Main points:

• The thing I don't understand is that the skin specific JS sheet (e.g. Minerva.js or Monobook.js) loads perfectly in all instances. Somehow the skin specific CSS sheet is missing in most instances. Why does it not follow the same logic path as is used to serve the JS?
• Once you've figured out the skin specific JS/CSS sheet to render, it should be a dead easy switch statement to display Mobile.js/.css if its Minerva, else Common.js/.css otherwise.
• Use of Mobile.js and Mobile.css seems entirely redundant when you've got Minerva.js and Minerva.css. If the logic to correctly load Common.js/.css was fixed, we could entirely remove Mobile.js and Mobile.css.