- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Tue, 25 Jul 2017 17:57:42 +0000
- To: public-webrtc-logs@w3.org
Good question. Firefox currently emits "track" before the promise resolves, and Chrome equivalently emits "addstream" before the promise resolves. That behavior makes sense to me; by the time a promise resolves, one would naturally assume everything associated with it is completed. I think this was my fault: https://github.com/w3c/webrtc-pc/pull/1136 It was my shortsighted attempt to ensure that when each track event fires, the `stream` in the event has a full list of tracks. But I didn't think about how that would affect ordering relative to the promise resolving. Assuming https://github.com/w3c/webrtc-pc/issues/1135 is still something we want to address, we could do it by saying "add the track event to a`[[pendingTrackEvents]]` internal slot" inside the "process the remote track" steps, and then after the "for each m= section" loop is finished, fire all pending track events. In other words, use an internal slot as a queue instead of the event queue. -- GitHub Notification of comment by taylor-b Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1508#issuecomment-317818464 using your GitHub account
Received on Tuesday, 25 July 2017 17:57:42 UTC