Maybe removeTrack should be a no-op on [[Stopping]] as well as [[Stopped]]?

[jan-ivar]

Similar to #2820 but for removeTrack (and no-op instead of rejection which is how removeTrack works).

The rationale would be the same that this method serves no purpose after 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.html

The red is Safari following the current spec, which says to proceed as long as the sender is in CollectSenders. The others aren't.

[jan-ivar]

In case your next question is who follows the spec on collectSenders and collectReceivers, this is (perhaps surprisingly) tested in https://wpt.fyi/results/webrtc/RTCDtlsTransport-state.html

The red is browsers following the current spec, the green is Firefox not (the test is from Mozilla and seems backwards). *

Given this, I think it makes sense to leave the sender in getSenders() on [[Stopping]] (current spec), ditto receivers, and fix the second test, but change the removeTrack spec language to abort explicitly if transceiver.[[Stopping]]

---

_{*) The test tests both getReceivers() and getSenders() but it tests getReceivers() first which is why the error message says getReceivers(). Presumably they work the same for senders and receivers.}

[jan-ivar]

This means fixing Safari and Firefox.

[jan-ivar]

(perhaps surprisingly)

We can remove those asserts, as this is instead correctly tested in RTCRtpTransceiver.https.html (wpt.fyi):

(Safari here appears to fail for an unrelated reason)