Last modified: 2014-02-12 23:32:43 UTC
In the file resources/mediawiki/mediawiki.js, function 'addScript', there's a branch which basically says: if ( $.isReady || async ) { // load JS resource via jQuery XHR } else { // load JS resource by doing a document.write of the <script> tag } The second block in that branch occasionally -- in our experience, in systems with large number of custom JS -- fails to work. The document.write simply does nothing; it neither writes the HTML code, nor emits an error. This occurs mostly in Chrome, but has also been observed in Firefox and IE. The problem seems to be that document.write will only succeed while still parsing the DOM; but the code appears to assume that if the DOM is not ready (i.e. if $.isReady is false), the source is still modifiable via document.write -- and apparently that's not necessarily the case; there appears to be a stage when the source has been parsed but DOM is not yet completely constructed, and under certain conditions the resource loader might find itself trying to load JS resources while in that 'gap'. This mostly manifests in the Editor, and occurs only when you click the 'edit' link; i.e. doing a full reload always forces the page to load correctly, but simply clicking, and thus letting browser use caches JS, occasionally manifests this error, wherein the JS extensions which modify the editor UI, are simply never loaded. Our krufty solution has been to put in a detector for certain JS files which the users are affected by the most, and load them by doing $('<script ...').prependTo('body') instead of document.write(). However, this solution is clearly not generalizable because it will doesn't guarantee the loading order reflective of the dependency tree. We don't know how to solve this problem "properly", but there clearly seems to be an hidden error in there, which only gets exercised when multiplicity of JS resources are loaded and affect the JS engine timing. The problem is not easily reproducible, but we at Vistaprint would be happy to work with MediaWiki developers to provide whatever platform and resources are necessary for reproduction and testing of the problem.
I recall there being another bug with the document.write path (in Firefox 4) in that it is sometimes ignored from an asynchronous script that runs before document ready. I wonder why we have this path at all. As far as I know asynchronous scripts (adding a regular <script> tag through DOM methods instead of document.write – the way we already do it after document ready) work fine before document ready as well. @RoanKattouw, @TrevorParscal: How about we just remove this case from the code and have it always append a script tag? (removing 'javascript' tag as this is more of a infrastructure/resourceloader matter)
So the reason we have it is for the top queue where we want the head load to be blocking, which afaik one can only do through document.write (and it is known to be safe when used there). We should, however, make sure that any subsequent calls (regardless of whether from a queue that isn't the top queue or from an asynchronous script) don't use that code path though, it'd be an opt-in thing for the top queue.
