Created attachment 575759 [details] Bug.html User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0a1) Gecko/20111117 Firefox/11.0a1 Build ID: 20111117030939 Steps to reproduce: Turn off your connection (Ethernet, Wifi & co.). Turn Firefox to the “work offline” mode. Close Firefox. Open the attached file (which only starts a new Websocket) in a new Firefox instance (normally in the “work offline” mode). Actual results: Firefox crashes :-(. Expected results: Starting a new Websocket in the “work offline” mode should throw an exception or should call the Websocket.onclose event.
this is wfm on linux, though it isn't hard to imagine how it could be os dependent. do you happen to have a stack trace?
I'm not reproducing on a local debug build from the 18th. Do you need to have a websocket server running?
Attachment #575759 - Attachment mime type: text/plain → text/html
Can't reproduce (Linux here).
I targeted Mac OS X. @Patrick: I don't have any stack trace :-/. @Josh: Even if my Websocket is running, the bug appears. I tried with a build from the 19th.
Ivan, just to confirm two things: are you saying that there's no crash report listed in about:crashes? Also, comment 4 isn't clear to me - can you reproduce the crash _without_ a websocket server running?
@Josh: It could be one of theses crashes: https://crash-stats.mozilla.com/report/index/bp-3907a952-a21c-4659-9c9f-bf3d82111122. No Websocket server is listening/running. I just have Firefox in “work offline” mode and my Bug.html file.
Thanks for the stack ivan! I suspect this is probably caused by 664894, but I'm not certain. you are exiting EstablishConnection early via a failed NS_ENSURE_SUCCESS path - probably asyncopen() given your network setup. That causes the nsAutoCloseWS class to call CloseConnection(), which in turn deref's mWebsocketChannel which is null because you're still in CONNECTING state and haven't finished EstablishConnection. The fix is just a null ptr check; I'll attach it shortly.
I have suspected something like this. Good to know you have a clue :-).
Created attachment 576134 [details] [diff] [review] patch 0
Attachment #576134 - Flags: review?(jduell.mcbugs)
status-firefox10: --- → affected
status-firefox11: --- → fixed
status-firefox8: --- → unaffected
status-firefox9: --- → unaffected
Attachment #576134 - Flags: approval-mozilla-aurora?
Assignee: nobody → mcmanus
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Attachment #576134 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox10: affected → fixed
Target Milestone: mozilla11 → mozilla10
I have verified this bug using the steps from the description on: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0) Gecko/20100101 Firefox/10.0 beta 2 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0 beta 2 and Firefox didn't crash. Setting resolution to verified on Beta.
status-firefox10: fixed → verified
Whiteboard: [qa+] → [qa+][qa!:10]
I've verified this bug using the steps from the description and Firefox did not crash. Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20100101 Firefox/11.0 beta 4 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20100101 Firefox/11.0 beta 4 Setting resolution to Verified Fixed.
Status: RESOLVED → VERIFIED
status-firefox11: fixed → verified
Whiteboard: [qa+][qa!:10] → [qa!]
You need to log in before you can comment on or make changes to this bug.