Closed Bug 704004 Opened 12 years ago Closed 12 years ago

Firefox in “work offline” mode crashes when starting a Websocket


(Core :: Networking: WebSockets, defect)

11 Branch
Not set



Tracking Status
firefox8 --- unaffected
firefox9 --- unaffected
firefox10 --- verified
firefox11 --- verified


(Reporter: ivan.enderlin, Assigned: mcmanus)


(Keywords: verified-beta, Whiteboard: [qa!])


(2 files)

Attached file 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:
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 :-).
Attached patch patch 0Splinter Review
Attachment #576134 - Flags: review?(jduell.mcbugs)
Attachment #576134 - Flags: review?(jduell.mcbugs) → review+
Target Milestone: --- → mozilla11
Attachment #576134 - Flags: approval-mozilla-aurora?
Assignee: nobody → mcmanus
Closed: 12 years ago
Resolution: --- → FIXED
Attachment #576134 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Whiteboard: [qa+]
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.
Keywords: verified-beta
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.
Whiteboard: [qa+][qa!:10] → [qa!]
You need to log in before you can comment on or make changes to this bug.