When going to: http://www.sky.com/home/ the Stop button and the Mozilla icon in the top right corner goes crazy! Build 20000517

this should all get fixed when rpotts lands his progress and loadgroup cleaning effort. ->rpotts.

Confirmed with 2000-05-18-08-M16 on WinNT. Just as important, the page never loads, Mozilla eats all available CPU, and Mozilla stops responding.

those are very optimistic words gagan :-) It turns out that the *real* problem is that http://www.sky.com/home has a javascript onLoad() handler which does a 'window.location.href=http://www.sky.com/home/GeneralIndex.html' This causes the current document to be cancelled. Unfortunately, nsWebShell::OnEndDocumentLoad(...) was ignoring the status of the load. So, it would execute the onLoad() handler again... introducing a loop which ultimately crashed the browser :-( I've got some code in my local tree to fix the webshell to *only* fire the load handlers if the document load was successful.

Arg... It looks like this is *not* the only problem... It appears that when a HTTP channel is cancelled, the NS_ERROR_BINDING_ABORTED error code is *not* propagated through the OnStopRequest(...). In nsHTTPChannel::Cancel(nsresult) FireNotifications() is called which uses NS_OK as its status code :-( I'm not sure yet if this is also contributing to the bug, but is is definately wrong!

it is really getting late :-( After looking at the HTTPChannel::Cancel() code some more, it appears that the correct status code *is* being propagated out through the OnStopRequest(...) A comment (or two) in the code explaining how/why everything works would be *very* helpful!!!

updated whiteboard...

cc'ing ruslan who might be able to help...

Well. If OnStop was queued up already and cancel was fired after that - the status won't get reflected of course. As we've discussed earlier - EVERY CONSUMER MUST check EXPLICITLY for the channel's status and not rely on the status provided in notification because of asynchronous nature of our events.

I have a fix for this bug... It is not really network related... -- rick

Crashing on build 2000061820

I've checkine in a fix for this...

Verified. Going to http://www.sky.com/home/ with build 2000062008 now correctly redirects to http://www.sky.com/home/GeneralIndex.html