- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Mar 2019 14:00:41 +0000
- To: public-webrtc-logs@w3.org
What we did in [media-capture](https://w3c.github.io/mediacapture-main/getusermedia.html#media-flow) when *setRemoteDescription()* needed a synchronous algorithm was this: > Whenever the User Agent initiates such a change, it MUST queue a task, using the user interaction task source, to [set a track's muted state](https://w3c.github.io/mediacapture-main/getusermedia.html#set-track-muted) to the state desired by the user. > > To **set a track's muted state** to *newState*, the User Agent MUST run the following steps: But we should have a good reason for doing this. The advice I've gotten from DOM folks is it's generally preferable, predictable and safer to always queue a task to fire an event. This is because [event dispatch](https://dom.spec.whatwg.org/#concept-event-dispatch), in spite of its name, is a synchronous function call directly into content JS. This means implementations (and specs) must be super careful about not making *any* assumptions about state in subsequent steps in the algorithm, since content JS may have changed state on us in all sorts of ways in the callback. This has led to crashes, even UAFs. What we had to do to make [set description](https://w3c.github.io/webrtc-pc/#set-description) safe, was write explicit steps that copied all state needed to fire the events, and then fire them all at once as the very last step. This way all observers experience the same state as well. In hindsight it would have been better if *setRemoteDescription()* fired a *single* event, but for compatibility reasons that was not a choice. Do we want to do that here? Does that reason hold here as well? -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2020#issuecomment-472867986 using your GitHub account
Received on Thursday, 14 March 2019 14:00:46 UTC