Closed
Bug 851997
Opened 11 years ago
Closed 11 years ago
Entire browser hangs after calling createDataChannel() before .onconnection() has fired
Categories
(Core :: WebRTC, defect)
Tracking
()
RESOLVED
FIXED
mozilla22
People
(Reporter: chris, Assigned: jesup)
References
Details
(Whiteboard: [WebRTC] [blocking-webrtc-] [qa-])
Attachments
(2 files)
Steps to reproduce using Nightly (these are complicated, but they reproduce 100% of the time when followed correctly): 1. Unzip the attached .zip 2. Load "webrtc-sender.html" in one tab and "webrtc-receiver.html" in another 3. Open the JS console on both tabs. 4. In webrtc-sender.html's console, type "pc1.localDescription" and hit return 5. Right click on the "offer" output and copy to clipboard. 6. In webrtc-recipient.html's console, type "handleOfferFromPC1(<paste>" 7. Trim the timestamp and one "(" from the front of the paste 8. Hit return to execute You should see: "Got remote stream / Attaching media stream / Got answer" 9. Still in webrtc-recipient's console, type "pc2.localDescription" and hit return 10. Right click on the "answer" output and copy to clipboard. 11. Back in webrtc-sender's console, type "handleAnswerFromPC2(<paste>" 12. Trim the timestamp and one "(" from the front of the paste 13. Hit return to execute You should see: "addstream / calling connectDataConnection" At this point, both sides of the connection have called connectDataConnection() with opposing ports, so there should be a DataConnection active. But the two .onconnection() callbacks haven't fired. I don't know why; I'm very interested in hearing where the bug is! Regardless, if at this point you run the following in webrtc-sender's console: dc1 = pc1.createDataChannel('test', {reliable:false}); You'll get a hard browser hang; backtrace attached. The hang reproduces whether or not reliable:false is provided, and no matter whether pc1 or pc2 calls createDataChannel().
Reporter | ||
Comment 1•11 years ago
|
||
Reporter | ||
Comment 2•11 years ago
|
||
Oops, s/webrtc-recipient/webrtc-receiver/g in the instructions above.
Reporter | ||
Comment 3•11 years ago
|
||
I tried reproducing on Windows XP with Nightly, it causes a full browser crash (instead of a full browser hang) there.
Reporter | ||
Comment 4•11 years ago
|
||
Windows XP crash report: https://crash-stats.mozilla.com/report/index/bp-7d8788af-5969-4a28-8988-d39c62130318
Assignee | ||
Comment 5•11 years ago
|
||
This is all getting totally reworked as part of bug 855623, so whatever the cause here it's likely to be moot shortly.
Assignee: nobody → rjesup
Status: UNCONFIRMED → NEW
Depends on: 855623
Ever confirmed: true
Whiteboard: [WebRTC] [blocking-webrtc-]
Assignee | ||
Comment 6•11 years ago
|
||
Should be fixed by checkin for bug 855623
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Updated•11 years ago
|
Whiteboard: [WebRTC] [blocking-webrtc-] → [WebRTC] [blocking-webrtc-] [qa-]
Reporter | ||
Comment 7•11 years ago
|
||
Thanks, confirmed fixed!
You need to log in
before you can comment on or make changes to this bug.
Description
•