W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2020

[webrtc-pc] Should not fire errors on closed datachannels (#2511)

From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
Date: Tue, 14 Apr 2020 19:40:22 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-599813009-1586893221-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Tuesday, 14 April 2020 19:40:26 UTC