Last modified: 2012-05-05 09:25:44 UTC
This is reproducible with Firefox 3.6 only, IE and newer Firefox versions seem to work. See my scripts at mw as example: [[mw:User:Schnark/common.js]] includes [[mw:User:Schnark/common.js/sub.js]], which binds a custom event and includes [[mw:User:Schnark/common.js/customevent.js]], which then triggers that custom event, so [[mw:User:Schnark/common.js/subpage.js]] is included. This script calls mw.loader.using. I must admit, that the this sounds strange, but in production there is some more code around this, so it actually makes sense. This doesn't break reliably, but most of the time I end up with a page only containing <html><head><script type="text/javascript" src="//bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&modules=jquery.ui.core%2Cdraggable%2Cmouse%2Cwidget&skin=vector&version=20120210T223051Z&*"></script></head></html>
(In reply to comment #0) > This doesn't break reliably, but most of the time I end up with a page only > containing Correction: It does always break on the main page and on [[mw:Special:Contributions/Schnark]], while I'm always able to see my user pages without problems. It seems that on pages from my browser cache it breaks less often than on other pages.
It seem like the custom event is necessary to reproduce the bug, but it doesn't matter whether I use document (original version) or mw (current version) as object to bind the event to.
Can you narrow down what is causing this? We had a similar problem with ?debug=true on commons. See bug 34664
I'm lowering the severity, since I can only reproduce it if: * there is a custom event * there are nested scripts * and when I use Firefox 3.6 Anybody crazy enough to use this combination should be able to work around this bug with some hacks (I replaced mw.loader.using with a variant that waits for DOM-ready before calling the original, and it works).
Side note: Please do not bind events to the mw object using jQuery Events. This is not supported, documented or encouraged anywhere. This is the first time I've seen such thing. Please create a new object and you're free to bind events to it that way. For example: mw.schnarkAwesomeTool = {}; $(mw.schnarkAwesomeTool).bind('custom-event', ..);
back to the original bug, I believe that is a duplicate of bug 34542.
I don't think bug 34542 is fixed. The "fix" in r112533 is only a workaround, not a definite resolution, as setting async argument to false still reveals the issue.
(In reply to comment #7) > I don't think bug 34542 is fixed. The "fix" in r112533 is only a workaround, > not a definite resolution, as setting async argument to false still reveals the > issue. I hadn't looked further into bug 34542. But yeah, it should be possible to load modules asynchronously and synchronously at any time.
(In reply to comment #5) > Side note: Please do not bind events to the mw object using jQuery Events. This > is not supported, documented or encouraged anywhere. This is the first time > I've seen such thing. Normally I bind to $(document), but I just wanted to try what happens when I use non-DOM-elements, and used mw as it is done in skins/common/preview.js. [https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/preview.js?view=markup] (In reply to comment #6) > back to the original bug, I believe that is a duplicate of bug 34542. I don't think so. Bug 34542 occurs with asynchronous scripts, while this bug is reproducible (only?) with Firefox 3.6, which doesn't implement async scripts.
Closing as WONTFIX: * This bug only occurred with Firefox 3.6.x, which is dead now. * It only occurred when a user put strange code in his common.js, not for "normal" users. * Nobody seems willing to debug it (I don't either), so there is no chance to fix it. * It might even be a browser bug, so nothing that can/should be fixed in MediaWiki. If anybody encounters the same issue in a situation where it should be fixed, it can be reopened, but for now I think this bug should just be ignored.
