[webrtc-pc] transceiver.stop() shouldn't block in-progress replaceTrack from succeeding (#2106)

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

== transceiver.stop() shouldn't block in-progress replaceTrack from succeeding ==
Most WebRTC methods' final queued task say:

   1. *If connection's [[IsClosed]] slot is true, then abort these steps.*

But [sender.replaceTrack](http://w3c.github.io/webrtc-pc/#dom-rtcrtpsender-replacetrack)'s says:

   1. *If transceiver's [[Stopped]] slot is true, abort these steps.*

That may seem like the sender-scoped equivalent, but has the side-effect that `transceiver.stop()` causes an already in-progress `replaceTrack` to never resolve. That seems unintended.

I propose we make them like the other.

One question then is should the promise resolve or reject with an error? I think resolving is fine, since it's a glorified setter at that point; no harm will come of it.

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

Received on Saturday, 16 February 2019 00:49:55 UTC