Last modified: 2013-04-24 15:19:41 UTC
Created attachment 12169 [details] Screenshot showing a debug window and the error console Where? At Wikimedia Commons. How to reproduce? * Use FF 20.0.1 (older versions are reported having the same behaviour) * Reset account preferences or create fresh account. * Go to user pages like https://commons.wikimedia.org/wiki/User:Bidgee (then Wikilove will trigger the issue) or go to http://commons.wikimedia.org/wiki/User_talk:FlickreviewR/bad-authors?debug=true (try anon and logged-in) Reproducible? Difficult. Does not always happen. Took me also a while to get it. But if you once have it, it happens always. What happens? -Visible to everyone If you have a slow machine you see the page content (boxes, colors, letters) for a short time and then, it vanishes (leaving a blank page) and Firefox seems to redirct to a WYCIWYG URL (https://commons.wikimedia.org/wiki/File:Wyciwyg.jpg). -Visible with debugging tools mw or jQuery or mediaWiki are supposed to be undefined. However, I can't say whether the error logged before the page vanished or after. Here is the HTML content of the blank page: <html><head><script src="//bits.wikimedia.org/commons.wikimedia.org/load.php?debug=true&lang=de&modules=ext.gadget.libAPI&only=scripts&skin=vector&version=20130412T161949Z&*"></script></head></html> This all leads to the conclusion that document.write is used where it should not be used (after document finished loading). Note that Commons has *a lot of JavaScript loaded through RL* I am not sure whether it is a MediaWiki or a Firefox bug. Were there recent changes affecting RL? Expected behaviour: No blank pages. ----- Error from the FF JS Error console (which is visible in the attached screenshot) Zeitstempel: 24.04.2013 14:46:45 Fehler: ReferenceError: jQuery is not defined Quelldatei: https://bits.wikimedia.org/commons.wikimedia.org/load.php?debug=true&lang=de&modules=ext.gadget.libAPI&only=scripts&skin=vector&version=20130412T161949Z&* Zeile: 921
*** This bug has been marked as a duplicate of bug 47457 ***
See also: * https://bugzilla.mozilla.org/show_bug.cgi?id=264811 (document.write() called after onload sends page to blank wyciwyg page) * https://bugzilla.mozilla.org/show_bug.cgi?id=788547#c2 (URL changes to wyciwyg://N/<old URL> after document.write) * https://bugzilla.mozilla.org/show_bug.cgi?id=619092 (wyciwyg URL is visible (document.write + stop + reload))
Hmm, this is strange. I checked, there are only a few areas where document.write is used: 1: Our bootloader script (where it should be safe, unless FF changed something in their implementation) 2: Our jquery's addScript(), where again it should be safe, since it's (should be) only a final fallback addition.
(In reply to comment #3) Can you give me the line/ code file for these occurrences so I can set breakpoints there to see what happens? Is there a way to search in gerrit?
Here is how to produce exectly the same error in Firefox at pages that load correctly: * Open Firebug (in the FF's native JS env, you'll get an error about an isecure operation), open the console tab * Execute: document.write('blabla'); * Execute: var x = jQuery;
Load the url with ?debug-true to simplify debugging (though it can affect load order) Then with Firebug, you can look for document.write using the widget in the top right of Firebug, that's easiest to find all occurrences.
Rainer: In bug 47457 comment 18 you wrote "sorry unduping. initial report is something else." but it's still marked as duplicate? If it *is* a dup, let's please move this discussion to bug 47457 to have it all in one place.
CC'ing some more WMF folks as this might be related to bug 47457 (some user pages do not successfully finish loading, mostly with Firefox).
For more info: *[[commons:Commons:Village pump#April 21]] *[[Bug 47457]]
(In reply to comment #8) > but it's still marked as duplicate After that (Bug 47457 comment 19), I wrote: "I am not entirely sure whether it is about slow pages or pages that go blank after loading." The Village Pump discussion seems to be about something else than the bug description (comment 0) (In reply to comment #8) > do not successfully finish loading Are you sure you quoted the right bug number? "Not successfully" does not sound like a blank page but like a half-broken page.
Oops. Links corrected. For more info: *[[commons:Commons:Village pump#April_21]] *Bug 47457 I helped write this, and so I should pay more attention: *[[Wikipedia:Bugzilla]]
(In reply to comment #6) * ?debug-true does not work (no difference)? Did you mean ?debug=true which only works if this is not a query-url like in edit mode where one has to use &debug=true But RL behaves different when using debug=true and not using it and compact code is not really debuggable in Firebug. Here is what I found out at http://commons.wikimedia.org/wiki/User_talk:FlickreviewR/bad-authors?debug=true (see comment 0) The call to https://bits.wikimedia.org/commons.wikimedia.org/load.php?debug=true&lang=de&modules=ext.gadget.libAPI&only=scripts&skin=vector&version=20130412T161949Z&* was marked as blocking (not async). When I used a conditional break point to intercept it (details below), the page does not vanish (so this bug does not appear) but gadgets relying on it do not complete loading. ####################### Conditional breakpoint [/libAPI/.test(src)] at: document.write( mw.html.element( 'script', { 'src': src }, '' ) ); in Function: function addScript( src, callback, async ) { where src= //bits.wikimedia.org/commons.wikimedia.org/load.php?debug=true&lang=de&modules=ext.gadget.libAPI&skin=vector&version=20130412T161949Z&* callback= null async= false with Stack: addScript < doRequest < work < request < using < anonymous
