[webrtc-pc] Semi-sync replaceTrack API pre-initial-negotiation is bizarre.

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

== Semi-sync replaceTrack API pre-initial-negotiation is bizarre. ==
As mentioned in this [chrome bug](https://bugs.chromium.org/p/chromium/issues/detail?id=811265), `replaceTrack` is spec'ed to be [semi-synchronous when](https://w3c.github.io/webrtc-pc/#dom-rtcrtpsender-replacetrack) the *"transceiver is not yet associated with a media description"*.

As I recall, this was a compromise reached long ago out of concern there'd be no way to synchronously set a track in time for createOffer, and was made before createOffer became impervious to these timing issues.

But this leaves users with a bizarre API: **if an error happens,  they won't know which one until later**. So it's never a fully synchronous API even in the pre-negotiation phase.

Users would have to write:
```js
sender.replaceTrack(newTrack);
if (sender.track != newTrack) {
  throw Error("An error happened, but we don't know which one (yet)!");
}
```
...if they were called synchronously and are expected to throw an exception for errors.

Of course, if they're not then they can get the error after the fact:
```js
let p = sender.replaceTrack(newTrack);
if (sender.track != newTrack) {
  await p; // rejects
}
```
... but then it begs the question why they're not just using:
```js
await sender.replaceTrack(newTrack);
```

FWIW I think we'd be happy to change Firefox to match Chrome here, and fix the spec.

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

Received on Monday, 12 February 2018 15:54:54 UTC