Webrtc-pc: Should a signalingstatechange event be fired when closing a RTCPeerConnection?

[youennf]

According https://bugs.webkit.org/show_bug.cgi?id=174314#c0, both Firefox and Chrome are firing http://w3c.github.io/webrtc-pc/#event-signalingstatechange when close() is called.
The spec does not seem to mandate this though.
Is it just a matter of updating implementations?

[alvestrand]

Offhand, I'd rather update the specification. It seems a bit strange to not fire the event when the state changes (although we skip firing an event in some other cases, like track.stop()).

[fippo]

known bug: https://bugs.chromium.org/p/chromium/issues/detail?id=699036
General rule is "don't fire events from user actions" iirc. Over to @jan-ivar :-)

[jan-ivar]

Looks like we decided this before: https://github.com/w3c/webrtc-pc/issues/1020

[alvestrand]

Sigh. every time we revisit, I like the resolution slightly less. But yes, we have made the call.

[aboba]

@jan-ivar @fippo Yes, we've been removing events fired as a result of user action. Not sure we've gotten them all, but don't think we want to add more.

[lgrahl]

Err... does that affect events fired by RTCDataChannel? Because certainly onclose fires when closing a data channel.

Also, that is such a weird behaviour to not fire due to user actions, it makes debug logging pretty awful... can we maybe revisit that for NV?

[jan-ivar]

Because certainly onclose fires when closing a data channel.

@lgrahl That seems true of channel.close(), on both ends to boot (the benefit of a data channel).

But not pc.close whose sole mention of data channels (unless I'm missing something) is:

"Set the [[ReadyState]] slot of each of connection's RTCDataChannels to "closed"."

However, both Chrome and Firefox appear to fire close on both ends of a data channel on pc.close(), when I run this fiddle (type "pcclose" in the chat).

There's a difference though: a data channel can be closed remotely, whereas a peer connection cannot.

The workaround for this in practice is to open a data channel: channel.onclose = e => pc.close().

So I think we should at least fix the pc.close steps here to align with implementations when it comes to closing data channels, as this works and seems useful.

[jan-ivar]

such a weird behaviour to not fire due to user actions, it makes debug logging pretty awful...

For better or worse, we have had this pattern since forever in both MediaCapture and WebRTC.

I think it partly comes out of a desire meet the "minimal API" test (if it can be polyfilled, polyfill it). For instance, if we decide to fire these events, this needs to be specified exactly. Case in point, Chrome and Firefox both fire an event on pc.close, but do it differently (Firefox fires before pc.close returns, missing any close handler added right after, whereas with Chrome it works, presumably it queues a task to fire it asap?)

As you point out, this assumes a monolithic application.

But partly, I think this also started with streams, a container for both local and remote tracks. E.g. stream.addTrack(track) does not fire addtrack on stream, only pc.setRemoteDescription does. Here, there are arguably two informal classes of tracks (remote and local), and the addtrack API was added explicitly only to solve a problem with remote ones.

I think these are the two factors that led us down this path. I don't think the consistency argument runs any deeper than this, but at some point we just need to pick one and stop changing our minds (and the spec).

[jan-ivar]

In case it wasn't clear, I'm arguing for an exception for data channels, saying pc1.close() should fire close on both ends of a data channel, because A) that is useful, and the only way to detect remote closing of a peer connection, and B) it's a workaround for the fact that closing of peer connections isn't advertised to the other end.

[lgrahl]

@jan-ivar Mhh... looking at it now, I can't quite follow you. Why would it be useful to fire the close event on the local peer when closing a data channel locally?

Furthermore, we do have the SCTP transport state (if anyone would implement it). That should be sufficient for the purpose of detecting a closed remote peer connection (technically, an aborted or shut down SCTP association), right?

Edit: We should probably move this slightly off-topic discussion to #1821 (you can reply there).

[jan-ivar]

Sorry I closed this issue by accident on account of a datachannel side-question.

[jan-ivar]

And it was decided in https://github.com/w3c/webrtc-pc/issues/1020, I remember now. Closing again. sorry for the noise.