Which one do you mean, common or global CSS & JS? They are two separate concepts, of which the latter is provided by an extension, and I'd argue that it certainly makes sense to load global CSS & JS on all skins, since, well, that's kinda the definition of global.

common.js is loaded on mobile. global.js isn't. Related:
T155304
T147755

In T156426#2974388, @ashley wrote:

Which one do you mean, common or global CSS & JS?

Oops. Sorry, I am talking about Common files.

With respect to the confusion around the name MediaWiki:Common.css - yes it's name would suggest it would load on all skins, but sadly this was written at a time before mobile so many MediaWiki sites have content in here which is not applicable to mobile devices. Hence we created Mobile.css (note Common files will work on the desktop version of the mobile skin).

This seems to be working as expected to me @Iniquity
can you provide more information please?

MediaWiki:Common.css does not load on the Minerva skin for me.
See https://en.m.wikipedia.beta.wmflabs.org/wiki/MediaWiki:Common.css:

.skin-minerva #mw-mf-page-center {
	background-color: red !important;
}

This would apply if it was loaded on the mobile skin.

Likewise a console.log from https://en.m.wikipedia.beta.wmflabs.org/wiki/MediaWiki:Common.js would show in mobile if it was being loaded on mobile.

You are confusing MediaWiki:Common.js with Special:MyPage/common.js

I dont know what Special MyPage is. What extension provides this? This would be an issue with that.. Not mobilefrontend. We are not purposely disabling it.

Special:MyPage goes to the user's own user page, so Special:MyPage/common.js goes to the user's own common.js subpage, which would be User:Nirmos/common.js for me on enwiki.

This sounds like a ResourceLoader bug.

@Krinkle any ideas what might be going on here?

I already explained what is happening in the task marked as duplicate: T155304#2953862. Unless this is actually a different issue, it's MobileFrontend not playing well with ResourceLoader, rather than a ResourceLoader bug.

In T155304#2953862, @matmarex wrote:

MobileFrontend has its own 'mobile.usermodule', loaded in SkinMinerva, which loads this script. That's the first one you're seeing.

I don't see anything in there to prevent the core 'user' module from being loaded (which loads the User:<skin>.js for the current skin, which is Minerva on mobile). I suspect that results in it being loaded again.

The reason for this is probably change 06ab9c0942f66317b20130ed12e677607783a61e in MediaWiki core, which allowed the 'user' module to load on mobile sites.

---

'mobile.usermodule' (MobileUserModule class) is documented as follows:

/**
 * Alternative of ResourceLoaderUserModule for mobile web.
 * Differs from the user module by not loading common.js,
 * which predate Minerva and may be incompatible.
 */

However, I can see my own common.js being loaded on the mobile site. If my guess about the reason is correct, this has been happening for half a year now, and I haven't heard anyone complaining about this. I think the solution here is simply to remove 'mobile.usermodule' (and 'mobile.usermodule.styles').

Basically, we have two options:

1. Restore previous status quo: Rewrite mobile.usermodule to match current core's user and user.styles modules, but omit common.js,css again. And then somehow load these instead of user/user.styles. This would require non-trivial addition of workarounds and would add significant technical debt.
2. Reduce mobile.usermodule to only providing User "mobile.js" and "mobile.css" and let core load the normal "user" modules (User common.js,css and minerva.js,css). In that case, mobile must also remove their override of site so that MediaWiki:Common.js/css load normally. The absence of that module currently breaks user scripts as a user's common.js may call functions provided by the site's MediaWiki:Common.js - ResourceLoader explicitly provides this guarantee of execution order, despite loading async.

I think it's time to create a clear and simple roadmap that concludes with loading Common.js and Common.css the "normal" way. What are the requirements? Let's identify what actual performance or UX problems loading the "site" module would cause, and address them once and for all.

Their absence continuously adds technical debt and maintenance overhead for both end-users and developers alike. I believe the original justification for this setup was site performance. As member of the Performance Team, I disagree with this approach. It costs too much for too little return.

We can't operate a unique platform like MediaWiki without given our users the trust, respect, and the ability to do it "right". Just like other teams can't curate everything manually for Vector skin users, or users using assistive technology, or users of IE10, Mac users, etc. (See also T127268) We have to trust developers and users to be able to produce code with all these platforms in mind. It requires education, documentation, patience, trust - all the while keeping an eye out for issues and being there to address them.

Change 348480 had a related patch set uploaded (by Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Remove mobile user modules

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

Change 348480 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Remove mobile user modules

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

Resolved?