[webrtc-pc] Maybe removeTrack should be a no-op on [[Stopping]] as well as [[Stopped]]? (#2874)

jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:

== Maybe removeTrack should be a no-op on [[Stopping]] as well as [[Stopped]]? ==
Similar to https://github.com/w3c/webrtc-pc/issues/2820 but for removeTrack (and no-op instead of rejection which is how removeTrack works).

The rationale would be the [same](https://github.com/w3c/webrtc-pc/issues/2820#issuecomment-1431991798) that this method serves no purpose after [stop()](https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver-stop) which "will immediately cause the transceiver's sender to no longer send, and its receiver to no longer receive."

While it might seem like a no-brainer to align with our earlier decision on those similar methods, implementations aren't 100% aligned, so we need a decision. https://wpt.fyi/results/webrtc/RTCPeerConnection-removeTrack.https.htm
<img width="1409" alt="image" src="https://github.com/w3c/webrtc-pc/assets/3136226/d4f09f5b-5f0c-4ba1-a041-b7a01dc31013">
The red is Safari following the current spec, which [says](https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-removetrack) to proceed as long as the sender is in [CollectSenders](https://w3c.github.io/webrtc-pc/#dfn-collectsenders). The others aren't.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2874 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 31 May 2023 16:22:47 UTC