• 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