Stop button goes crazy: http://www.sky.com/home/

VERIFIED FIXED in M17

Status

()

P3
normal
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: bugzilla, Assigned: rpotts)

Tracking

({crash})

Trunk
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: have fix, URL)

(Reporter)

Description

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

Build 20000517

Comment 1

19 years ago
this should all get fixed when rpotts lands his progress and loadgroup cleaning 
effort. ->rpotts.
Assignee: gagan → rpotts

Updated

19 years ago
Summary: http://www.sky.com/home/ → Stop button goes crazy: http://www.sky.com/home/

Comment 2

19 years ago
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.
(Assignee)

Comment 3

19 years ago
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.
(Assignee)

Comment 4

19 years ago
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!
(Assignee)

Comment 5

19 years ago
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!!!
(Assignee)

Comment 6

19 years ago
updated whiteboard...
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: have fix
Target Milestone: --- → M17

Comment 7

19 years ago
cc'ing ruslan who might be able to help...

Comment 8

19 years ago
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.
(Assignee)

Comment 9

19 years ago
I have a fix for this bug...  It is not really network related...

-- rick
(Reporter)

Comment 10

19 years ago
Crashing on build 2000061820
Keywords: crash
(Assignee)

Comment 11

19 years ago
I've checkine in a fix for this...
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 12

19 years ago
Verified.

Going to http://www.sky.com/home/ with build 2000062008 now correctly redirects 
to http://www.sky.com/home/GeneralIndex.html
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.