As proof for this April fools day story a screenshot from an entirely different user. Not reproducable. Image has not been drawn for kidding.

In T113575#1669977, @PerfektesChaos wrote:

Image has not been drawn for kidding.

I don't understand what you'd like to express by that sentence.

Image has not been drawn for kidding.

I don't understand what you'd like to express by that sentence.

This image with unbelievable contents has not been faked by drawing program.

No one in deWP user space or gadget is touching this CSS module, and it is not very likely to depend upon that internal stuff:
https://de.wikipedia.org/w/index.php?title=Spezial%3ASuche&search=%22mediawiki.ui.anchor%22&fulltext=Search&ns2=1&ns8=1

I would expect MW itself to use this UI-CSS details.

The only thing that depends on 'mediawiki.ui.anchor' anywhere seems to be two modules in MobileFrontend. One of them ('mobile.talk.overlays') does call isAnon(), and I'm not entirely sure if the dependencies are set up right, but it looks like it would result in a different error message… – and besides, what would that be doing on non-mobile page loads?

I've checked MobileFrontend and there are no issues there (I tried loading all modules references mediawiki.ui.anchor with mw.loader.using in desktop skin and nothing throwed an error).

This bug needs further replication instructions (I see in the screenshot you were clicking show difference on an edit when this happened). Next time you hit the bug run mw.loader.inspect() in the console and tell us what shows up to give us more clues.

I suspect this is a gadget.

The lady who is providing us with screenshots might be overstrained by a request to “run mw.loader.inspect() in the console”.

However, before you wrote that comment she caught a longer report. Since it is quite long, I hesitate to write it right here, but I link an attachment:

I get a clear impression what’s going on here. This is not a regular script touching a module not yet ready now, not loading the correct dependencies, and getting the error message it deserves. In contrary, the displayed message text is wrong itself and affected by the error, and the tracking is invalid as well.

Those who have seen this behaviour are using wikieditor. It might be affected by something which is improving and configuring wikieditor on deWP, but the problem is not reported correctly, and nothing has been modified in this area for a long time – until RL processing has been changed and deployed last week.

Thanks @PerfektesChaos
Can you ask the lady to append &debug=true into the URL address bar?
If she can open the console and copy and paste the result she should also be able to copy and paste
mw.loader.inspect() there and get a dump of useful information.

With this we should be able to easily fix this bug, without it's near impossible to identify the culprit...

Well, @Schnark has opened this bug, and the chasing lust of a shark might have overcome him now, re-assigning this bug again, and it will be an easy job for him to play with mw.inspect as soon as arriving again.

• I checked that no script I'm using even references mediawiki.ui.anchor.
• This error should occur only when you call mw.loader.using( 'mediawiki.ui.anchor' ) before the module is loaded. Since Echo loads this by default, and the module is top-loaded, it seems very unlikely that any script actually could trigger this.
• There was one unguarded call to mw.user.isAnon in MediaWiki:Common.js, which might have something to do with this, but when really this is the cause it still is a MW bug that it is reported as an error in the callback for mediawiki.ui.anchor.

Please see https://phabricator.wikimedia.org/T113575#1672166 I really need a stack trace in debug mode and to know what mw.loader.inspect reports. Without that I can't get to the bottom of this without being able to replicate this bug.

The error message pointing to 'mediawiki.ui.anchor' could be misleading, since this code runs when a module becomes loaded and any of the modules which were pending has errors in the load callback. However, the set of modules which were pending should contain only 'mediawiki.ui.anchor'…

I think de.wp had some scripts which reached pretty deep into the bowels of ResourceLoader. Do you still use them and can you point me to where they are?

We are currently investigating another issue. The lady was told to include

mw.loader.load("https://bits.wikimedia.org/en.wikipedia.org/load.php?modules=ext.gadget.CollapsibleNav&skin=vector");

That one is not equipped to run outside its MediaWiki:Gadgets-definition, since it does not make double sure that jquery.cookie,jquery.tabIndex are available.

It was commented out yesterday, and the nuisance suspended now. If not occurring again, we will release it next weekend and see whether any and which stacktrace that might cause.

You could play with the errors yourself, but it is apparently a race condition depending on network and machine speed as well as other scripts and preferences being involved. I failed to reproduce any error for myself. However, the problems arrived with deployment of recent mediawiki.js update (major changes in queueing, beginning of September)

Some scripts use or used mw.loader.implement(), which worked fine for years until 20 days ago. It was not clear whether this might be involved into RL problems; therefore they are currently shifting or already migrated to mw.hook(), which has been released later and appears to be much more robust and foolproof, without any possible side effect.

I can replicate a similar bug when Zero is enabled.. T114128

@PerfektesChaos: As T114128 was resolved, does this problem still happen?