New DataChannels should never start in the "open" state
Categories
(Core :: WebRTC: Signaling, defect, P2)
Tracking
()
People
(Reporter: bwc, Unassigned)
Details
Spec says to create new DataChannels in the "connecting" state, and async update their state to "open" if/when is actually open. We're starting in "open" in cases where the connection is already established, and a new DataChannel is created.
|
||
Comment 1•5 years ago
|
||
I vaguely remember that there was some discussion around this topic already. But I don't remember the exact bug, maybe it was W3C GitHub issue. Unfortunately I'm not sure anymore about the final conclusion.
|
||
Comment 2•5 years ago
|
||
Check the webrtc/rtcweb logs, and perhaps the interim/etc notes. I do think it was discussed in one or the other forum
|
||
Comment 3•5 years ago
|
||
Nils, you're probably remembering w3c/webrtc-pc/issues/1761 (comment), where we left createDataChannel alone, but discussed the similar problem when the datachannel event fires. There, we settled on a kludge: data channels are observably open in ondatachannel, but the open event hasn't fired yet, so you can still register an onopen handler in ondatachannel and get the open event, even though it is already open, for backwards compatibility. This lets JS send immediately from ondatachannel.
As Taylor summarized, this gives us the best invariants:
const channel = pc.createDataChannel("x");
console.log(channel.readyState) // Always "connecting"
and
pc.ondatachannel = e => console.log(e.channel.readyState) // Always "open"
That is, regardless of other state.
|
|
||
Comment 4•5 years ago
|
||
Thanks for digging that up jib. Yes that is probably what I vaguely remember here as related.
|
Reporter | |
Comment 5•5 years ago
|
||
This was fixed in bug 1551589.
Description
•