On the latest build of FF OS (1.3.0.0-prerelease) when I go to this page with the browser (not as an installed app) it reboots the phone. I checked the error logs on my GP Peak device and it said: 'Boot Reason = 16' It loads fine on the stable build since there is no WebRTC support. Just had the same behaviour confirmed by Dietrich on Nexus 4, so I suspect this is a software issue?

That sounds really bad. QA Wanted - Can someone confirm this on a Buri device on 1.3? Also, does this reproduce on 1.2?

As a note about expected behaviour (assuming WebRTC video streaming is supported) - you should get a WebRTC prompt to allow access to a camera, then it shows your video stream in the site on the lower left hand corner. Then the messages should just stream in one by one. It doesn't get to the message streaming since it seems to be blocked by the WebRTC prompt (at least that's my guess).

(In reply to Jen Fong-Adwent [:ednapiranha] from comment #2) > As a note about expected behaviour (assuming WebRTC video streaming is > supported) - you should get a WebRTC prompt to allow access to a camera, > then it shows your video stream in the site on the lower left hand corner. > Then the messages should just stream in one by one. It doesn't get to the > message streaming since it seems to be blocked by the WebRTC prompt (at > least that's my guess). We actually haven't landed gUM camera support yet for 1.3 - it's going to land shortly. However, we shouldn't be hitting an OS restart crash here when trying to prompt for gUM in an unsupported format. I'm wondering if this problem is present on 1.2.

There are some bugs waiting to land before PeerConnection and gUM video are available on 1.3; bug 853356, 945066, and a few others. It shouldn't crash, but it won't work right now either.

I've tested this without the WebRTC prompt and can confirm it is a web socket issue when socket.io is loading the incoming data. Once the incoming data attempts to come in, the system reboots.

Jen, can you provide a simplified testcase?

This issue DOES reproduce on the 12/06 1.3 build. The phone freezes and then restarts. I attached a logcat that spans from loading the web page until the phone has completed restarting. This issue does NOT reproduce on the 12/06 1.2 build. The web page loads with posts from different users; no freezing or crashing. - 1.3 Build - Environmental Variables: Device: Buri v1.3 COM RIL BuildID: 20131206040203 Gaia: 8fca2ca67e8a6022fe6ed8cb576e5d59dfb5237f Gecko: 1401e4b394ad Version: 28.0a1 Firmware Version: 20131115 RIL Version: 01.02.00.019.102

Can you get a crash report ID from your device? https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Getting_crashes_off_the_Device

Reduced test case here https://dl.dropboxusercontent.com/u/1913694/test_b2g.html (says 'socket error on nightly' on the url bar before rebooting)

(In reply to Jen Fong-Adwent [:ednapiranha] from comment #10) > Reduced test case here > https://dl.dropboxusercontent.com/u/1913694/test_b2g.html (says 'socket > error on nightly' on the url bar before rebooting) The reduced test case doesn't use getUserMedia, so this isn't a WebRTC bug. Socket.IO is a cross-platform web socket library, so I think this likely a web sockets crash.

there's really nothing actionable here yet on the platform-websockets side.. nightly is happy with it and the websocket code is totally cross platform so that's a pretty decent indicator it isn't in that code. (though not conclusive, of course). Is there a stack or something that more definitively makes you think this is a ws issue?

Crash Report ID: bp-73532956-7f74-4b37-8cff-397482131206

CountRecvBytes and CountSentBytes are called on the socket thread, and they call SaveNetworkStats which can only be called on the main thread. The HTTP channel implementation avoids this by using runnables for calling SaveNetworkStats.

(In reply to Matthew Vaughan from comment #13) > Crash Report ID: bp-73532956-7f74-4b37-8cff-397482131206 Known crash - and we've got a reduced test case now. It's XPCOM crash.