Last modified: 2013-10-03 22:24:34 UTC
(Possibly related or same thing: bug 31895) As reported to me on pl.wiki[1], ResourceLoader's addScript() function sometimes uses the document.write variant after the document is already loaded. Firefox ignores this (to avoid clearing the document), resulting in scripts not loading. (Or at least that's how I interpret the message.) Full error message (in Polish) was: [15:07:34.698] Zignorowano wywołanie document.write() z asynchronicznie pobranego skryptu zewnętrznego. @ http://bits.wikimedia.org/pl.wikipedia.org/load.php?debug=false&lang=pl&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20121105T173042Z:152 The only thing in that code mentioning document.write() is addScript(). The document.write way is marked with a FIXME and apparently half-broken - why are we even using it? [1] https://pl.wikipedia.org/w/index.php?title=Dyskusja_wikipedysty:Matma_Rex&oldid=33447258#Odp:Problem_z_disFixerem
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=commitdiff;h=67d400e727af98f8c74c1c21a5003372f33291e4 set the async property for some <script>s, and https://developer.mozilla.org/en-US/docs/HTML/Element/script#Attributes says: "Never call document.write() from an async script.", this might be related.
Michael, your link is broken, but `git log --grep=async` tells me you probably meant change I04f1775213633e.
There is an open bug for this somewhere, it hasn't caused any issues because we never use document.write from an asynchronous script (and .async property set in I04f1775213633e is irrelevant as the <script> element method is already asynchronous by default). If it does cause any reproducible issues we could get rid of that optimisation, though we would need to come up with an alternative way to do blocking loads from the <head>.
Either way, we don't care about low-priority browser warnings for potential problems. Please attach reproduction steps for tangible issues (i.e. module X doesn't load when following steps Y and Z).
Unfortunately I wasn't able to reproduce it myself, and I was told that it just happens from time to time. I've asked the user to ping me should something interesting happen, he's no programmer, but a pretty savvy guy. My investigation was prompted by his report that a certain gadget on pl.wiki stopped loading after recent changes to it; maybe you or other RL gurus could skim through the code for mw.loader-related issues, it uses three mw.loader calls, and two of the three gadgets it loads this way use mw.loader further. (Unfortunately these are not translated, but the code is mostly in English.) The gadget is: https://pl.wikipedia.org/wiki/MediaWiki:Gadget-disFixer.js - it displays a button that allows the user to fix disambiguation links on the page. The dependencies are (skipping CSS files and local JS config, see all the stuff at https://pl.wikipedia.org/wiki/MediaWiki:Gadgets-definition): https://pl.wikipedia.org/wiki/MediaWiki:Gadget-gConfig.js - a configuration manager for gadgets, IMO a pretty fine thing that I'm going to polish and try to share with other wikis some day https://pl.wikipedia.org/wiki/MediaWiki:Gadget-mark-disambigs.js - finds and marks disambiguation links on page https://pl.wikipedia.org/wiki/MediaWiki:Gadget-sk.js - general, slightly overengineered :( code cleanup module - it loads even further modules...
This might be the same as bug 50746. Either way I'm closing myself as non-reproducible in practice.
