Last modified: 2013-04-29 22:24:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 34542 - mw.loader.load calls document.write from asynchronous scripts
mw.loader.load calls document.write from asynchronous scripts
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
All All
: Highest normal (vote)
: 1.19.0 release
Assigned To: Roan Kattouw
Depends on:
Blocks: 31217
  Show dependency treegraph
Reported: 2012-02-20 10:36 UTC by Michael M.
Modified: 2013-04-29 22:24 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Screenshot: using mw.loader.load('...', '...', true) (151.44 KB, image/png)
2012-02-24 10:25 UTC, Michael M.
Screenshot: using mw.loader.load('...', '...', false) (146.78 KB, image/png)
2012-02-24 10:28 UTC, Michael M.

Description Michael M. 2012-02-20 10:36:02 UTC
While debugging a user script I came across this bug, which may be responsible for some of the issues occurring in the last time.

Tested MediaWiki version is 1.18wmf1, browser is Firefox 10.0.1. The script doesn't call document.write anywhere directly, so all calls to document.write are done by mw.loader.load.

I found several warnings in the web console, saying
 A call to document.write from an asynchronously loaded extern script was ignored.
(translated from German, original: Ein Aufruf von document.write() durch ein asynchron geladenes externes Skript wurde ignoriert.)

So mw.loader.load should pay attention not to load anything by document.write unless this definitely can be done without problems. In this case several scripts were just missing.
Comment 1 Mark A. Hershberger 2012-02-21 02:23:09 UTC
RL has really changed since 1.18 so I doubt this problem is still around.   Could you test with SVN head or the 1.19 branch?
Comment 2 Michael M. 2012-02-21 08:57:57 UTC
(In reply to comment #1)
> RL has really changed since 1.18 so I doubt this problem is still around.  
> Could you test with SVN head or the 1.19 branch?

The main change is that RL is now even faster, which means that document.write is used more often. The problem is reproducible on beta.wmflabs:

1. Visit
2. Enable the gadget markAdmins ("markAdmins markiert auf Spezial-, Benutzer-, Diskussions-, Projekt-, Datei- und Hilfeseiten sowie in Versionsunterschieden und der Versionsgeschichte Benutzer mit erweiterten Rechten.")
This gadget loads the real script with mw.loader.load. It should append an (A) to all usernames who are sysops.
3. Visit
Since most of the users are sysops you should see an (A) after many usernames (at least Umherirrender (A/B), and Schnark (A)). But with Firefox 10 they are missing, instead you will find the above warning in the log. In browser which don't implement async loading like Firefox 3.6 and IE 8 the gadget works as expected.

This bug seems to be the explanation for bug 34517, so I'll adjust milestone and importance to match those of 34517.
Comment 3 Roan Kattouw 2012-02-21 18:00:26 UTC
There is code in mediawiki.js that ensures that document.write() is not used after document ready. I don't know how we'd prevent this in a better way.
Comment 4 Chris McMahon 2012-02-21 18:48:57 UTC
I am unable to reproduce the issue described in Comment 2 using FF 9.  The "A" and "A/B" markers appear correctly.
Comment 5 Chris McMahon 2012-02-21 18:56:43 UTC
nor can I reproduce it with Chrome 17
Comment 6 Chris McMahon 2012-02-21 19:17:24 UTC
no reproduction, closing
Comment 7 Michael M. 2012-02-22 09:03:31 UTC
(In reply to comment #3)
> There is code in mediawiki.js that ensures that document.write() is not used
> after document ready. I don't know how we'd prevent this in a better way. says:
"In Firefox 4.0, the async DOM property defaults to true for script-created scripts" (i.e. almost all scripts in a typical page served by MediaWiki are async scripts) and "Never call document.write() from an async script. In Gecko 1.9.2, calling document.write() has an unpredictable effect. In Gecko 2.0, calling document.write() from an async script has no effect (other than printing a warning to the error console)." And I don't think that 'never' means 'only before document ready'. The English warning is "A call to document.write() from an asynchronously-loaded external script was ignored."

Since no gadgets are working at the moment (probably some caching issues) I can't test the bug, but I'm quite sure that this really is a bug that needs to be fixed as soon as possible.
Comment 8 Michael M. 2012-02-24 10:25:22 UTC
Created attachment 10087 [details]
Screenshot: using mw.loader.load('...', '...', true)

I can still reproduce the issue with Firefox 10 on wmlabs.beta. I changed the call to mw.loader.load to use three parameters. When I use true for the third parameter everything works, no matter how often you reload the page. See screenshot.
Comment 9 Michael M. 2012-02-24 10:28:53 UTC
Created attachment 10088 [details]
Screenshot: using mw.loader.load('...', '...', false)

But when I use false for the third parameter I sometimes get the warning about an ignored document.write, and the marks are missing. See screenshot.

The only difference is, that in the first case document.write is definitely not used, while in the second case it is used. Since there is obviously a bug in the second case document.write mustn't be used there, either.
Comment 10 Beau 2012-02-24 15:44:06 UTC
Reproducible on pl.wikisource using Chromium 17.0.963.56 and Firefox 10.0.1.
Comment 11 Roan Kattouw 2012-02-27 22:47:16 UTC
Fixed in r112533 by making the third parameter (async) default to true if a URL is specified, and to false otherwise. Will deploy this to the live site in a minute.
Comment 12 Gerrit Notification Bot 2013-04-29 22:24:24 UTC
Related URL: (Gerrit Change Ic3d0c937268d0943d2f770f3ca18bcf4e1eed346)
Comment 13 Gerrit Notification Bot 2013-04-29 22:24:47 UTC
Related URL: (Gerrit Change Ic3d0c937268d0943d2f770f3ca18bcf4e1eed346)

Note You need to log in before you can comment on or make changes to this bug.