W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2017

[webrtc-pc] Ordering of stream "addtrack"/"removetrack" events vs. "track" event

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Thu, 14 Sep 2017 01:56:22 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-257571329-1505354172-sysbot+gh@w3.org>
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:

== Ordering of stream "addtrack"/"removetrack" events vs. "track" event ==
This is equivalent to https://github.com/w3c/webrtc-pc/issues/1568, but for the "addtrack" and "removetrack" events rather than "mute".

The "When the User Agent initiates adding/removing a track" algorithm we reference implicitly from mediacapture-main queues a task, which means events will happen after the "track" event rather than before. If we want them to fire before, we need to make the algorithm in mediacapture-main more flexible (see comments towards the end of https://github.com/w3c/webrtc-pc/pull/1519).

This is desirable, because `event.streams` are fully populated by the time the `"track"` event fires:
```js
pc.ontrack = event => console.log(event.streams[0].getTracks().length); // 2
```
...so you'd expect an `onaddtrack` added at that point to only hear about future tracks:
```js
pc.ontrack = event => event.streams[0].onaddtrack = () => console.log("even more tracks!");
```
This is how [implementations work](https://jsfiddle.net/jib1/5wzj6a7h/). You would **not** expect to hear about those already in there (spec).

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1599 using your GitHub account
Received on Thursday, 14 September 2017 01:56:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:51 UTC