55975 - no onLoad if page contains images and all fail to load

Status: VERIFIED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[Keith Lesch]

Using build 2000100920:

The following attached file takes approximately 25 seconds to load and does NOT 
fire the onload event.

File summary: The file attempts to load about a dozen images, none of which will 
be found.  The onload event simply attempts to alert().  IE executes this page 
in less time than you can measure.

I have acquired this testcase from a very complex file that would not fire its 
onload event.  I continued to remove HTML and script until I came up with this.  
In my original testcase, the images exist, although it only loads one.  My 
original page loads in 2 seconds, but does not fire the onload event.

Comment 1

[Keith Lesch]

Attachment: 25 seconds to load, onload does not fire.

Comment 2

[Loco]

Could this be related to the current incarnation of bug #21162?
http://bugzilla.mozilla.org/show_bug.cgi?id=21162

Comment 3

[Loco]

Confirming on Mac 10-09-10 build.  Bad behavior.  This seems like a big deal.  
Throbber stops throbbing after about 4 seconds, but onLoad never gets fired (in 
4.x it displays a net little message).

Comment 4

[Loco]

Seems important enough to harass PDT.  Increasing sev/pri and nominating for
RTM.  This could potentially have far reaching implications...The end is near...

Comment 5

[Jason Eager]

AHA...and this might be related to my problems with fixing Netscape's start up
page (bug# 51013)

Comment 6

[Nisheeth Ranjan]

Re-assigning to myself for further investigation...

Comment 7

[Jesse Ruderman]

Updating summary.

Could this have been broken by the fix to bug 52526?

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I do not think this was caused by 52526. Is this a regression, can you show a
build where this does work?

I looked this a bit in the debugger. The place where we send the load event is
in DocumentViewerImpl::LoadComplete(). In this case the input parameter aStatus
is NS_FAILED, so we do not send the load event. I do not yet know why the input
parameter shows NS_FAILED(). It is set to NS_FAILED() in
nsOnStopRequestEvent::HandleEvent() which gets it from channel, but this is how
far I have investigated this.

Comment 9

[Keith Lesch]

I can't say for sure if I've ever seen this work.  I have recently started 
developing with dedication to having my code working with Mozilla, and this is 
one of the things I have run into.  What's even WORSE is that MY images are 
actually there and the page doesn't find/load them!  :-(

Comment 10

[Nisheeth Ranjan]

This is working in today's windows rtm branch build so I'm guessing that this is
fixed on the trunk also.  The onload handler fires for the attached testcase.
Keith, could you go ahead and test with the latest mozilla nightly build?
Marking rtm- to get off the rtm radar.

Comment 11

[Keith Lesch]

Yes, it looks good to me.  I would "resolve" the bug but I'm not sure whether 
you fixed it or it just started working as a result of something else...I would 
be glad to verify after someone else updates the state.

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Marking worksforme.

Comment 13

[Keith Lesch]

Verified on build 20001030, theres usually a longer number but I don't see it 
anymore!  Is it still around somewhere?

Comment 14

[Jesse Ruderman]

I think the builds that don't display build numbers at the top are branch 
builds.  Worksforme on a trunk build (Win98 2000103004).

If you want to control whether you get a trunk build or a branch build, you 
have to look through http://ftp.mozilla.org/pub/mozilla/nightly/ for a recent 
build for your platform.  For some reason, mozilla/nightly/latest/ sometimes 
contains branch builds (the ones that will go into Moz 0.6 and NS 6.0) and 
sometimes contains trunk builds (the ones that will be used for future 
development and future versions).