- From: Adam Bergkvist via GitHub <sysbot+gh@w3.org>
- Date: Thu, 24 May 2018 11:27:17 +0000
- To: public-media-capture-logs@w3.org
To answer your last question first; this is indeed the right place to ask this kind of question. :) The rationale for not firing the events when API modifies the tracks of a `MediaStream` is that those operations are synchronous. I.e., after adding a track, you can check on the next line that the new track is in place. The purpose of the events are notify the script that something has happened asynchronously, and the first time the new change will be visible (the track addition or removal) is in the event handler as the change is done synchronously with the event being fired. We don't fire events with synchronous API since the script can detect it anyhow, as you describe above, and that it can cause strange behavior. For example that the event notifies about something that is no longer true, since the "change" has already happened and is not done in sync with the event firing. For example, by the time the firing of an `addtrack` event is picked up the main thread, the track could have been removed by the script or some other queued task. I think you're case when the script doesn't own the `MediaStream` is special, and therefore requires some special handling in code. -- GitHub Notification of comment by adam-be Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/517#issuecomment-391680432 using your GitHub account
Received on Thursday, 24 May 2018 11:28:00 UTC