hta@/guidou@ WDYT?

This is a bug according to the spec, but I'm not sure it should be.

The code says:

disableButton.addEventListener('click', event => {
  window.stream.getVideoTracks()[0].enabled = false;

The spec says:

When all tracks connected to a source are muted or disabled, the "on-air" or "recording" indicator for that source can be turned off; when the track is no longer muted or disabled, it must be turned back on.

There's a privacy issue here in that it's possible to disable the track, then enable it, take a picture and disable it again; likely this will cause such a brief flash of the indicator that users won't notice.

There's also a practical issue for the cameras that (correctly IMHO) hardwire the recording indicator to the open state - closing the camera on "disable" means that it has to be reopened and reinitialized on "enable", and there's also no protection against other apps taking away the camera in the meantime.

My summary: I think the behavior is what it should be, but the spec doesn't say what I think it should say. I'll raise an issue on the spec about that.

Yes there would be a privacy issue if all indicators of the device being open were removed. The spec refers to an "on-air" indicator, which I think can be interpreted as such, which I agree would be bad.

However, I think the intent of the spec here (which is a MAY anyway) is to let UAs tell their users the device is muted, so they don't have to stare at the camera light wondering if mute really took, or if the site is lying and still recording.

FWIW we're planning to turn off the device instead (so that the camera light goes out) and leave, but perhaps slightly alter its red indicator with a slash through it to indicate this new "shared but muted" state (because mics don't have lights). See https://bugzil.la/1299515

Our thinking is that since track.enabled is the spec-promoted API for muting, we want people to use it, which they won't until we fix it. Anyway those are our plans. Hope it helps.

+felt for Enamel's opinion on indicators. (Please redirect if someone else is handling media stuff.)

In Chrome, with our remembered-by-default permissions, it's straightforward to .stop() the stream, and then use getUserMedia to re-open it for the picture without a prompt. So, turning off the camera on .enabled=false only worsens the privacy issue for Firefox and Edge-in-http-mode, not us. *We* need to make sure that the indicators for recording always stay on for a minimum length of time, even if the camera was opened and closed quickly.

I agree that it might be a problem if .enabled=true could fail because another application reserved the camera exclusively. Should the spec make this operation a function instead of an assignment in order to allow that, and to allow the operation to take time by returning a Promise? I checked on my macbook, and it seems like 2 applications can have a camera open at the same time, but maybe that's not true on all OSes.

A user can unplug their USB camera at any time anyway, even during track.enabled == false, so firing an "ended" event should suffice (the spec used to include an error here, but it was removed, so probably not a big concern). FF internally stops and restarts the camera during applyConstraints, so not sure how important it is that setting track.enabled to true is frame accurate? Maybe there's even a way to reserve hardware without turning it on, we'll see. 

I've checked with people who know more, and they confirm that on many cameras, the only way we can turn off the camera indicator light is to power off the camera (which the drivers will do if we close it).

+raymes for permissions questions

I'm not sure I fully understand everything but I think err-ing on the side of keeping the light on longer is safer. 

raymes, should we leave the camera light on even if the stream is .stop()'ed, as long as the page has permission to re-open the camera using getUserMedia()? This would cause hangouts to keep the light on even while the video is muted.

I don't feel too strongly. We probably wouldn't want the light to come on before the page has used it, even though it could use it without prompting. So if we turn it off when it's stop'd I guess that's ok as long as there is a minimum time that it stays on so the user can be aware.