Re: [mediacapture-transform] How does generator.mute change track states? (#81)

> I was assuming that "queue a task" passes its arguments by value, not by reference

[Queue a task]( doesn't take custom arguments, just _steps_. So I read _"queue a task to do X"_ as:
 1. Queue a task to run the following _steps_:
     1. Do X.

If X is _"Use this.[[[isMuted]]]( for something"_, then "this" is dereferenced when the queued task executes.

This is similar to the [forEach closure problem in JS](

> The second description makes it clear that it is pass-by-value, so that may be the better formulation of what I intended to say.

Got it. But I still think that's undesirable. The `track.muted` API was designed to be called by the user agent, and to be observed by JS as well as downstream sinks implemented by the user agent.

With VideoTrackGenerator, we're opening up a way for JS to act as an underlying device, giving JS a new form of control surface that gives it new ways to control downstream and existing written JS. I think being conservative here means keeping some control over what JS can do in this new role, which to me means limiting things like setting muted many times in a row on the same task, which would be something downstream hasn't seen before, expands what we need to test for, and doesn't seem to serve any purpose 

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Tuesday, 1 March 2022 23:19:15 UTC