Last modified: 2013-07-11 14:37:46 UTC
There are a few ways that resource loader is used after DOM ready, but before its handler for this event is invoked. There may be userscripts running in the users browser that can do that. What happens is: # the userscript adds a DOMready-handler # the scripts get loaded, jQuery adds its handler, mw.loader is initialisized # the dom is finished # the userscripts handler gets invoked and from there mw.loader is called # as the loaders "ready" variable is still false, it uses document.write # the document crashes very ugly To prevent that, the userscript should be able to set the ready variable to true. I propose to make the function, which is used as the callback argument to jQuery.ready(), a public property of the loader object.
Another solution could be (untested) to fire the document ready event from the bottom of </body> with jQuery.ready(). Another solution would be to have mw.loader use jQuery.isReady directly instead of a local `var isReady = false; $(function () { isReady = true; });` which, as you say, will be X invocations behind.
Did that in I146c1d2245aae71c538ce84daee30b4ec490b874. This bug is still possible since jQuery's domready callback list isn't the only callback list for DOMContentLoaded. The native browser event has this list as well. Therefor not marking this bug as resolved yet. We can further improve this by firing ready() from the bottom of the </body> (but before </html>). This optimizes overal performance and gets us in right before the native event, still playing safe.
This is actually done now as a solution to bug 47457.
