@Lokal_Profil can you share a URL too?

site is not available on mobile. I'm not sure why this is being marked as dependency of something. It sounds like a gadget is depending on this. @Krinkle any ideas what might be happening here?

@bmansurov can you reproduce now with the steps i've added?

Yes, I see it's happening now. For those who want to see it in action:
https://commons.m.wikimedia.org/wiki/Special:History/User_talk:Bmansurov_(WMF)

@bmansurov to be clear - you saw it happening when following the steps in the description on a local instance?
Note I cannot replicate it on https://commons.m.wikimedia.org/wiki/Special:History/User_talk:Bmansurov_(WMF) as I don't have your gadget so it's a little confusing sharing that link.

I was not able to reproduce it locally. I don't think I have gadgets either on commons.

By gadget I mean this (mine is empty which is why I cannot replicate). What do you see when you test locally with the above steps? Is it possible you don't have $wgAllowUserJs = true; set locally?

After adding $wgAllowUserJs = true; I see the error locally too.

I can reproduce this in production, on commons.m.wikimedia.org. I only have a common.js page on my user account, no minerva.js and it still causes the error.

This is caused by the mobile site now loading the "user" module (it used to have its own version of the user module). This module has a hardcoded internal dependency on the "site" module since its execution must happen after the site module finished loading. This is a legacy requirement that has always been the case with user scripts since they cannot explicitly express this dependency anywhere else.

Before 2015, when our script loading was still synchronous, this was implicitly done by one being after the other in the HTML as separate script tags. Now that loading happens asynchronously, this is ensured by ResourceLoader. This has been the case since at least August of last year.

Since MobileFrontend has a custom user and site module without the 'common.js' portion, the only remaining script is minerva.js which has presumably has had an expectation from very early on that it does not depend on the site-wide Minerva.js script.

In T147755#2706213, @Jdlrobson wrote:

I'm not sure why this is being marked as dependency of something. It sounds like a gadget is depending on this.

It's not being loaded by a gadget. It's loaded directly from the HTML output:

<script>(window.RLQ=window.RLQ||[]).push(function(){
mw.loader.load("/w/load.php?debug=false\u0026lang=en\u0026modules=mobile.usermodule\u0026only=scripts\u0026skin=..user=Krinkle..);
mw.loader.load([..]);});</script>
..
<script>(window.RLQ=window.RLQ||[]).push(function(){
mw.loader.load("/w/load.php?debug=false\u0026lang=en\u0026modules=user\u0026skin=..user=Krinkle..

@bmansurov @ovasileva Any more analysis needed or can we schedule this work (move to triaged but future)?

I do't see this problem any longer. was it solved ?

The error message in the console went away after rMW7e2e2db806f6: mw.loader: For using() errors, reject Promise instead of throwing. The site module is still not available on mobile (and shouldn't be, per MobileFrontend design). And as before, the user module will continue to execute unaffected after ResourceLoader fails to load the implicit site dependency.