264811 - document.write() called after onload sends page to blank wyciwyg page

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Refrozen Webmaster]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; rv:1.7.3) Gecko/20040913 Not-Google/1.3.3.7 (Not-The-1337-Google-Bot)
Build Identifier: Mozilla/5.0 (Windows; U; Win98; rv:1.7.3) Gecko/20040913 Not-Google/1.3.3.7 (Not-The-1337-Google-Bot)

The page http://search.refrozen.com/ loads perfectly in other browsers, in
FireFox, it seems to redirect to wyciwyg:/4/.... The bug seems to be on and off,
after Googling for wyciwyg it appears to be associated with many bugs, and has
to do with caching, so I cleared my cache, rebooted, and everything the bug
still occurs, I got other people to test it, and it occured for them too.

Maybe has to do with my javascript that occurs at the bottom of the page?

Reproducible: Sometimes
Steps to Reproduce:
1. Open Mozilla Firefox PR 1.0, navigate to http://search.refrozen.com
2. Watch page load.
3. Wait, and watch page disappear when finished loading.

Actual Results:  
The page loaded, then disappeared and kept saying 'Loading'.

Expected Results:  
Rendered the page, allowed the user to decide what to do, like a normal page.

The page does include, right near the very end. You can view the JS file at the
URL in the HTML. 

<script language="javascript1.2" src="http://www.refrozen.com/js/menu.js"></script>
</body>
</html>

Comment 1

[Peter van der Woude [:Peter6]]

W3C
http://validator.w3.org/check?uri=http%3A%2F%2Fsearch.refrozen.com%2F

the page is a mess, but supprisingly is rendered by Opera and IE

Comment 2

[Refrozen Webmaster]

(In reply to comment #1)
> W3C
> http://validator.w3.org/check?uri=http%3A%2F%2Fsearch.refrozen.com%2F
> 
> the page is a mess, but supprisingly is rendered by Opera and IE

Your right, it is a mess, but I stiiiiiiiiil think the bug has something to do
with the JS rendering.

Comment 3

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20041001
Firefox/0.10.1

I tried once and the page rendered.

Comment 4

[Chris Meiering]

I see this bug all the time in Firefox on OSX using the nightlies. It almost
always happens when I am loading multiple tabs and is not restricted to a
specific page. 

Not sure if this comment is best here or in bug#245588

Comment 5

[tim_liddelow]

I am fairly certain this is the same bug - go to 
http://www.php.net/security-note.php
and watch the same behaviour.  Noted on WIN32, Windows XP, Firefox 1.0.
Browser sits there trying to load page.

Comment 6

[Tom Quetchenbach]

(In reply to comment #5)
> I am fairly certain this is the same bug - go to 
> http://www.php.net/security-note.php
> and watch the same behaviour.  Noted on WIN32, Windows XP, Firefox 1.0.
> Browser sits there trying to load page.
> 

The problem with the PHP site is that document.write() gets called from within
http://www.php.net/functions.js, albeit in a horribly obfuscated way, after the
page loads. You're not supposed to do that, are you?

Comment 7

[Julien Muchembled]

See also http://bugs.php.net/bug.php?id=31466 for the problem with the PHP site.
So... FF bug ?
It worked 2 days ago.
(XP / FF 1.0)

Comment 8

[Tor Arvid Lund]

*** Bug 277744 has been marked as a duplicate of this bug. ***

Comment 9

[Boris Zbarsky [:bzbarsky]]

This sounds like the page is calling document.write() after onload.  Minimal
testcase would help.

Comment 10

[D.W. Edwards]

This bug looks very similar to one that I have encountered. Loading this page:

http://catandgirl.com/game.php

results in a few graphics entities being rendered, but the php script is totally
ignored with respect to the major content. This happens every time I access a
page  with a php script, not just this page. Browser spends a long time trying
to transfer content, then sits there with a more or less blank page apart from
the non-php HTML elements.

This occurs regardless of window count or tab count. Browser fails to respond to
all php pages. Yet IE handles the page without problems.

Since I can reproduce this every time, with any randomly selected php page that
I visit, I suspect that it's the part of the code responsible for handling php 
scripts. Is there a plug-in that provides a workaround in the meantime?

Comment 11

[Samuel Sidler (old account; do not CC)]

Confirming. We're seeing this on Camino as well right now. Working on a testcase.

-> Core

Comment 12

[Brendan Eich [:brendan]]

Use the right component, then -- document.write is DOM level 0, not JS engine.

/be

Comment 13

[Wevah (Nate Weaver)]

Attachment: Minimal testcase.

Here's a super-reduced testcase based on the salon.com page Samuel and I were
seeing this on. The Salon ad writes a script tag with a location change, then
writes out something else right after.

(You can see a reduced, two-element Salon ad script that will trigger this at
http://judo.salon.com/RealMedia/ads/adstream_mjx.ads/www.salonmagazine.com/home.html/@TopLeft,TopRight
)

Comment 14

[Brendan Eich [:brendan]]

Thanks for the reduced testcase.  We should get this fixed for 1.8b4.

/be

Comment 15

[Boris Zbarsky [:bzbarsky]]

This is basically a duplicate of our bug on location changes stopping the
pageload, no?

Comment 16

[Johnny Stenback (:jst)]

Taking bug, I'll look into this one...

Comment 17

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: potential patch

Stealing from jst.

This patch actually works, but I haven't tested it extensively. I think that
this does the Right Thing (tm). With this patch, we don't null out the parser
if we're in the middle of evaluating a script (or, if we're not in the middle
of a document.write()). It seems that nsHTMLDocument::EndLoad will set the
termination function on the currently executing script, which is the right
thing to do here.

Comment 18

[Blake Kaplan (:mrbkap) (inactive)]

Just to note: I tested my patch a bit more today, moving each <script> element
out into external files (which I thought would break, despite my patch) and they
all redirected successfully to google, so I think (barring some bad side-effect
of my patch that I'm not (fore)seeing) that my patch is correct.

Comment 19

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Use a better check

Comment 20

[Johnny Stenback (:jst)]

Comment on attachment 196233 [details] [diff] [review]
Use a better check

r=jst

Comment 21

[Brendan Eich [:brendan]]

Comment on attachment 196233 [details] [diff] [review]
Use a better check

sr=me, although I would've asserted !mIsWriting if !mWriteLevel ;-).

/be

Comment 22

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into trunk. I'll check this in on the branch tomorrow.

Comment 23

[Samuel Sidler (old account; do not CC)]

*** Bug 308711 has been marked as a duplicate of this bug. ***

Comment 24

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into MOZILLA_1_8_BRANCH.

Comment 25

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050917
Firefox/1.6a1

SeaMonkey 1.1a:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050917 Mozilla/1.0