Summary: Merck.com renders, then loads a blank page and appears to never finish loading
This works fine in 3.0.x
Steps to Reproduce:
1. Using trunk, load http://www.merck.com
Merck.com finishes loading
Initially Merck.com renders, but then flashes to a blank page and never finishes loading
Error: syntax error
Source File: http://www.merck.com/screenresolution.html?width=1920&height=1200
Line: 1, Column: 62
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
Is it possible that this happens because of some UA sniffing.
Or if not, what is the regression range?
I set |general.useragent.override| to Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:18.104.22.168) Gecko/2008092417 Firefox/3.0.3, and it still doesn't work.
Sadly, I don't really have time right now to find a regression range, but maybe later tonight.
I do have an HTTP log, but not sure if that would be helpful.
I am seeing this with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081024 Minefield/3.1b2pre. Funny thing is, it says "Stopped" in the toolbar, and yet the working animation is still going. I am also getting a lot of
Error: return not in function
Line: 1, Column: 1
In the Error console, with some other junk. Can provide the rest if wanted.
Based on the following snippet, I'm not sure this is in the correct component, but hopefully biesi or someone else would know.
0: nsHttpResponseHead::MustValidate ??
0: no mandatory validation requirement
0: Not validating based on expiration time
0: CheckCache [this=2598f10 doValidation=0]
0: nsHttpChannel::ReadFromCache [this=2598f10] Using cached copy of: http://www.merck.com/scripts/jquery121.js
0: nsHttpConnectionMgr::RescheduleTransaction [trans=33eed30 10]
0: STS dispatch [19f5c60]
0: nsHttpChannel::Cancel [this=25986a0 status=804b0002]
0: nsHttpConnectionMgr::CancelTransaction [trans=33eed30 reason=804b0002]
0: STS dispatch [19f5e80]
0: nsHttpConnectionMgr::RescheduleTransaction [trans=33ed3e0 10]
0: STS dispatch [19f5fc0]
0: nsHttpChannel::Cancel [this=2598340 status=804b0002]
0: nsHttpConnectionMgr::CancelTransaction [trans=33ed3e0 reason=804b0002]
There are a bunch of repeating STS dispatch -> nsHttpChannel:Cancel -> nsHttpConnectionMgr:CancelTransaction calls.
Created attachment 344726 [details]
I'm not 100% sure, but I believe this is due to a document.write() call after onload.
Fails: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/2008080504 Minefield/3.1a2pre
Works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/2008080403 Minefield/3.1a2pre works
Jonas, could this be fallout from bug 28293?
It sounds plausible given the description of what happens. But I don't see any elements with the 'defer' attribute set. There might be one hidden deep in there somewhere though.
The page <http://www.merck.com> is invalid (67 Errors, 33 warnings)
Christopher, I think we are agreed about that. The question is, what id causing this, and why, and should it?
I think the reason is that Merck.com has got sloppy Web developers. If anyone at Merck takes time to clean up that mess and Firefox still blanks, it would be an interesting thing to investigate. But examining that stinking dead corpse of a HTML page? I am not volunteering.
@Christopher, first, I know that the Merck website is a mess. However, the question is not, "Does Merck need to get better devs", but "Should, based on that Code, Firefox be showing a blank page".
The script <http://www.merck.com/scripts/screenres.js> is called early, its actual purpose is unknown. It seems to do nothing except that it makes an XMLHttpRequest to the page the trunk version ends up displaying. I cannot see any connection to the DEFER functionality here.
Maybe someone should volunteer to contact the Merck developers to ask them on what their take is on the situation. Maybe Stephen since he was the reporter, and presumably was using the site. This could end up being moved over to Tech Evangelism if necessary.
Created attachment 345534 [details]
Created attachment 345535 [details]
So I created this testcase from the HTML I get when I do "save page". Which looks distinctly different from what I see with just view source. E.g. view source doesn't show any deferred script elements, but there's four of them in the saved source.
Still, I'm guessing that for the testcase itself it doesn't matter...
(In reply to comment #17)
> Created an attachment (id=345535) [details]
Does the page stop loading when the deferred script:
a) tries to write a META element into the HEAD?
b) tries to write a DIV element into the BODY?
Christopher: No. Neither of those changes causes the page to stop loading.
Sander: Thanks for the testcase! This helps tremendously.
However it looks like IE8 is doing the same thing that we are doing on the testcase. Any idea why merck.com works while FF3.1 doesn't?
(sorry, that should of course say, "why IE works but FF3.1 doesn't")
Created attachment 345593 [details]
This shows the difference with IE8.
Basically, the page uses swfobject, which sets innerHTML, and somehow that makes the difference.
Created attachment 345613 [details]
Wow, that is freaky. Attaching a minimal singlefile testcase.
Talked with jst and what we'll do is to move execution of deferred scripts to before we drop the parser so that document.write always result in things getting appended to the end, rather than replace the page.
Thanks a ton for creating the testcase Sander! Saves me a lot of time.
In any case, I would expect document.write to a closed document to silently fail, not reopen, IMHO. The current Firefox behavior <https://developer.mozilla.org/en/DOM/document.write> is an extension to the standard where this case is undefined.
(In reply to comment #24)
I also wonder if this is the same bug that seems to prevent http://www.ford.com from loading sometimes as well?
Created attachment 351633 [details] [diff] [review]
Patch to fix
This should do it.
The idea is to delay calling DidBuildModel until all deferred scripts have finished running. I also decided to defer it until all pending scripts have run, so that if someone does something like
s = document.createElement('script');
s.src = "data:text/plain,document.write('foo');";
there won't be a race condition which might blow away the whole document.
One concern with the patch is, is it safe for the parser to run scripts at the point when ReadyToCallDidBuildModel is called?
(In reply to comment #27)
> One concern with the patch is, is it safe for the parser to run scripts at the
> point when ReadyToCallDidBuildModel is called?
I think it's safe for the parser, but it appears that we started firing DOMContentLoaded asynchronously for bug 344305, comment 18.
*** Bug 457679 has been marked as a duplicate of this bug. ***
Progress on this, Jonas?
I've created bug 473361. It's been mentioned that it could be this bug, but in myfax.com.
Blake: I talked with bz and it seems like the better fix for bug 344305 is to improve SetupNewViewer instead since there are more places where stopping a channel can cause scripts to execute.
This was backed out for failing unit tests.
Still leaks :(
Created attachment 358783 [details] [diff] [review]
Fire DOMContentLoaded after deferred scripts
This fires DOMContentLoaded at the same place it used to, after the called to EndLoad. This means that it'll fire after all deferred scripts have executed.
Created attachment 358981 [details] [diff] [review]
Fix on top of previous one. This should fix mochitest failures as well as leaks.
Comment on attachment 358981 [details] [diff] [review]
Add a comment about the mInternalState check and r+sr=me.
This is IN! Woot!
http://hg.mozilla.org/mozilla-central/rev/d524c8d6a4fb (main patch)
http://hg.mozilla.org/mozilla-central/rev/e43a978789a9 (fix additional problem)
Verified FIXED on 1.9.1: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b3pre) Gecko/20090128 Shiretoko/3.1b3pre
Replacing fixed1.9.1 keyword with verified1.9.1.
Also verified as fixed on trunk:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090128 Minefield/3.2a1pre
Thanks for finding and verifying this Stephen!
It looks like this fix broke deferred scripts in XHTML (as in, the document won't parse at all). See bug 478889.
Tests are in the patch
This bug is back on the latest trunk builds... manifesting itself on dabs.com causing the homepage to redirect to verisign....
Probably because of bug 518104. Given our experience with this bug, I'm surprised the spec says what it does.
Can you please file a new bug. It would be great to have a minimized testcase. We are behaving fairly close to IE now (though not exactly like IE since IE is crazy)
dabs.com works fine for me using Firefox trunk on Mac, fwiw.
You might have to enable html5 (html5.enable) but it certainly doesn't work for me (page gets "blanked" after a little while of loading).
Yes, it gets blanked if I set html5.enable to true.
That's probably a wholly unrelated to this bug then. Please file a separate bug.
sicking, what's the reason for not setting readyState to "interactive" when the parser is aborted? I see no spec-based justification for going straight from "loading" to "complete".
"loading" means that we're still downloading the main document and will eventually fire both "DOMContentLoaded" as well as "load" events.
"interactive" means that we're still downloading resources that the document depends on and will eventually fire a "load" event.
"complete" means that no more downloading is happening and that no more events will be fired.
Out of these I think "complete" seems to be the best fit as to what state we're in after aborting. Possibly we could mint a new "aborted" and/or "error" state but I haven't thought through if that would add more confusion than it would solve.
Either way it seems like this bug is a bad place to discuss this. Maybe start a whatwg thread? (though I think you might have already done so).