- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Mar 2016 04:06:00 +0000
- To: public-webrtc@w3.org
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc: == pc.close() never fires any events. On purpose? == [pc.close()](http://w3c.github.io/webrtc-pc/#widl-RTCPeerConnection-close-void) never [updates the ICE connection state](http://w3c.github.io/webrtc-pc/#update-ice-connection-state) to `"closed"`, and never fires a simple event named [signalingstatechange](http://w3c.github.io/webrtc-pc/#event-signalingstatechange) at *connection* with `"closed"`. Intentional? The spec seems unclear: The text on [signalingstatechange](http://w3c.github.io/webrtc-pc/#event-signalingstatechange) says "The signaling state has changed. This state change is the result of either setLocalDescription() or setRemoteDescription() being invoked. " (which seems to exclude close). But then the explanation for [*onsignalingstatechange* said until recently](https://w3c.github.io/webrtc-pc/archives/20151123/webrtc.html#widl-RTCPeerConnection-onsignalingstatechange) (the removal seems editorial): "It is called any time the RTCPeerConnection signaling state changes, i.e., from a call to setLocalDescription, a call to setRemoteDescription, or code. It does not fire for the initial state change into new." (which seems to suggest it fires for `"closed"`). If they are to fire, I have questions about whether they're to fire synchronously (in which case we need to deal with reentrancy), or whether they are to be queued in a task, and if the latter whether the setting of the state is to be queued as well. Arguably, with the merge of https://github.com/w3c/webrtc-pc/pull/552 there is no need to fire these anymore, since the peer connection will never close on you. Looking for clarification. Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/565 using your GitHub account
Received on Wednesday, 30 March 2016 04:06:02 UTC