- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 Apr 2020 19:40:22 +0000
- To: public-webrtc-logs@w3.org
alvestrand has just created a new issue for https://github.com/w3c/webrtc-pc: == Should not fire errors on closed datachannels == The following text describes what happens when transports close: https://w3c.github.io/webrtc-pc/#announcing-a-data-channel-as-closed When an RTCDataChannel object's underlying data transport has been closed, the user agent MUST queue a task to run the following steps: * Let channel be the RTCDataChannel object whose underlying data transport was closed. * Set channel.[[ReadyState]] to "closed". * If the transport was closed with an error, fire an event named error using the RTCErrorEvent interface with its errorDetail attribute set to "sctp-failure" at channel. * Fire an event named close at channel. Per https://bugs.chromium.org/p/chromium/issues/detail?id=1069811 it seems that the naive implementation of this caused "error" to be fired even when the datachannel was previously closed. This seems a bit silly. Suggestion: Add as step 2: "If the channel.[[ReadyState]] is already closed, abort these steps." Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2511 using your GitHub account
Received on Tuesday, 14 April 2020 19:40:25 UTC