Bug 303052 – RTCDataChannel close event does not fire if RTCPeerConnection closes

• Status: RESOLVED
• Resolution: FIXED
• Component: WebRTC

Created attachment 477495 [details]
Minimal HTML page to reproduce the issue

We're observing a difference in behaviour between WebKit (20624.1.2.19.2) and browsers such as Chrome (142.0.7444.176) and Firefox (145.0.1) when closing the RTCPeerConnection that creates an RTCDataChannel with createDataChannel.

To reproduce, you can use the attached HTML page and try the following in the JavaScript console:

> pc1.close()

I expect it to log the message "[DC] Closed" to the console as it is has an event listener registered on the data channel. I also expect it to change the readyState of the data channel to "closed" however it remains "open" and no event or handler is fired.

In Chrome and Firefox, the "[DC] Closed" message is logged and the data channel readyState becomes "closed".

However, running the following:

> pc2.close()

Does cause the event and handler to be fired showing that one of the peer connections closing triggers the event (the end of the connection that _didn't_ create the data channel) but the other end (the one that created the data channel) doesn't.

It's worth noting that this case doesn't seem to be covered by the web platform tests for data channel closing (see https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCDataChannel-close.html) as the "other" end of the peer connection is always the one that is closed and there is no test that a close event listener fires when the initial peer connection is closed.

[youenn fablet]

Interesting, I think the spec is mandating to not fire a closed event but we might need to check this with Chromium and Mozilla teams.

For what it is worth: the real life use case we have here is that we use a data channel to proxy VNC traffic between a browser and a remote device. If the remote device end closes without warning (e.g. by sending a KILL signal to the process), we're not receiving the close event on our data channel in Safari but we do receive it in Firefox and Chrome. The VNC client library we're using only accepts the data channel itself as a sort of socket argument so is unaware of the related Peer Connection and therefore has no idea the connection has closed.

[youenn fablet]

The issue I understand is the following:
- pc1 has a data channel with pc2. pc1.close() is called. Data channel close event fires on Firefox and Chrome, but not Safari

> If the remote device end closes without warning (e.g. by sending a KILL signal to the process), we're not receiving the close event on our data channel in Safari but we do receive it in Firefox and Chrome

The issue I understand from here is that pc1 has a data channel with pc2 and pc2 disappears unexpectedly.
I would expect data channel close event to fire here.

Can you validate this is the former you are after and that the usecase you mention here is tied to it?

(In reply to youenn fablet from comment #4)
> The issue I understand from here is that pc1 has a data channel with pc2 and
> pc2 disappears unexpectedly.
> I would expect data channel close event to fire here.
> 
> Can you validate this is the former you are after and that the usecase you
> mention here is tied to it?

That is correct.

[youenn fablet]

https://github.com/w3c/webrtc-pc/issues/3085

[Radar WebKit Bug Importer]

<rdar://problem/165617848>

[youenn fablet]

Pull request: https://github.com/WebKit/WebKit/pull/55471

[EWS]

Committed 304859@main (e83716d17383): <https://commits.webkit.org/304859@main>

Reviewed commits have been landed. Closing PR #55471 and removing active labels.