Open Bug 478277 Opened 11 years ago Updated Last year

Firefox 3 onload and DOMContentLoaded event firing before the page is fully loaded (2).

Categories

(Core :: DOM: Events, defect, P5, major)

x86_64
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: smitpe29, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.6) Gecko/2009020410 Fedora/3.0.6-1.fc10 Firefox/3.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.6) Gecko/2009020410 Fedora/3.0.6-1.fc10 Firefox/3.0.6

I am re-entering Bug #444322. This is still happening, even on the test url I supplied. If I refresh that page multiple times, I will see 
The expected output is: scott.

The actual output is: undefined

just as this page specifies. I see this in my dojo application, the javascript will just die silently. This has gotten better no doubt after this patch.

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/21419305fd8f

sometimes i think its worse when caching is disabled (which I do through the ff web dev toolbar). I also wonder if firebug exacerbates this problem.

Reproducible: Sometimes

Steps to Reproduce:
1.refresh url http://gchris.googlepages.com/444322.html
2.repeat (could be a while) try caching disabled.
3.
Actual Results:  
watch for that 

The expected output is: scott.

The actual output is: undefined

Expected Results:  
Should always be "scott"

I have the latest firebug 1.3 installed as well as the web dev toolbar. Others have seen this as well. This affects dojo applications badly due to their reliance on the domContentLoaded event.
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: general → events
Summary: Firefox 3 onload and DOMContentLoaded event firing before the page is fully loaded. → Firefox 3 onload and DOMContentLoaded event firing before the page is fully loaded (2).
Pete, can you try again with a nightly build tomorrow? The fix that should fix this went in on that branch today.
ok will do and follow up.
I downloaded http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-3.2a1pre.en-US.linux-x86_64.tar.bz2 , unzipped and ran ./firefox ? which started "minefield" and I cannot reproduce this bug with the url above. Is this the proper way to test the beta? I tried typing firefox or ./firefox but it always luanched my default 3.0.6 build from fedora.

P
I would swear, this got worse after FF 3.0.7, could coincide with a Firebug update to 1.3.3. I can barely work today, have to refresh constantly to get javascript to fire up.
Not blocking 1.9.1 based on comment #3.
Flags: blocking1.9.1? → blocking1.9.1-
That comment is testing an m-c build.  Have we tested this on the 1.9.1 branch?
We're having an issue that I believe might be related to this one. We have a syncronous XMLHttpRequest call on the page header, as other people here have described. Sometimes, not always, when the page loads, all the HTML after the call on the header is simply discarded. This leads to a blank page. This is happening on FF 3.0.7 and 3.0.8, both on Windows and Mac (I have not tested on Linux).

It's a bit hard to create a test case, given this is an WebObjects application and you would need to have the necessary environment working. However, this is a public web application (currently in beta, www.survs.com ) and I can create an account for you guys to test (I can explain the testing procedure by email, it happens more than 25% of the times the offending page is open).
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.