W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2019

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

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Sat, 16 Feb 2019 00:49:54 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-411004344-1550278193-sysbot+gh@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:55 UTC