Bug 1596959 Comment 4 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Firefox's privacy guarantee is that once camera/mic indicators go away, they cannot come back unless users checked the box.

> We looked at keeping a reference to the microphone streams, but the microphone streams work best when they are closed out prior to playing audio prompts.

You should be able to work around this using the following:
```js
if (isFirefox) {
  keepalive = stream.clone();
  for (const track of keepalive.getTracks()) track.enabled = false;
}
```
Everything should behave as before, except you'll see gray (not red) camera/mic indicators in the URL bar when everything is off, and they'll turn red again instead of you being re-prompted when you request access anew.

See https://blog.mozilla.org/webrtc/better-privacy-on-camera-mute-in-firefox-60/ for more details.

Unfortunately, other browsers haven't followed suit, with sites like Hangouts still doing hacks (relinquishing the stream) when you click on the camera mute button (presumably to get the hardware light to go off on mute in Chrome), which causes annoying re-prompts in Firefox on unmute. Ironically, had they merely set `track.enabled = !muted.checked` as the spec intended, Hangouts would have worked as expected in Firefox.

I've opened [w3c/mediacapture-main#642](https://github.com/w3c/mediacapture-main/issues/642) to push the other browsers on this.

Happy to leave this open for discussion, but unless the permissions team wishes to pick this up, I don't think the media team has any plans for changes here.
Firefox's privacy guarantee is that once camera/mic indicators go away, they cannot come back unless users checked the box.

> We looked at keeping a reference to the microphone streams, but the microphone streams work best when they are closed out prior to playing audio prompts.

You should be able to work around this using the following:
```js
if (isFirefox) {
  window.keepalive = stream.clone();
  for (const track of keepalive.getTracks()) track.enabled = false;
}
```
Everything should behave as before, except you'll see gray (not red) camera/mic indicators in the URL bar when everything is off, and they'll turn red again instead of you being re-prompted when you request access anew.

See https://blog.mozilla.org/webrtc/better-privacy-on-camera-mute-in-firefox-60/ for more details.

Unfortunately, other browsers haven't followed suit, with sites like Hangouts still doing hacks (relinquishing the stream) when you click on the camera mute button (presumably to get the hardware light to go off on mute in Chrome), which causes annoying re-prompts in Firefox on unmute. Ironically, had they merely set `track.enabled = !muted.checked` as the spec intended, Hangouts would have worked as expected in Firefox.

I've opened [w3c/mediacapture-main#642](https://github.com/w3c/mediacapture-main/issues/642) to push the other browsers on this.

Happy to leave this open for discussion, but unless the permissions team wishes to pick this up, I don't think the media team has any plans for changes here.
Firefox's privacy guarantee is that once camera/mic indicators go away, they cannot come back unless users checked the box.

> We looked at keeping a reference to the microphone streams, but the microphone streams work best when they are closed out prior to playing audio prompts.

You should be able to work around this using the following:
```js
window.keepalive = stream.clone();
for (const track of window.keepalive.getTracks()) track.enabled = false;
```
Everything should behave as before, except you'll see gray (not red) camera/mic indicators in the URL bar when everything is off, and they'll turn red again instead of you being re-prompted when you request access anew.

See https://blog.mozilla.org/webrtc/better-privacy-on-camera-mute-in-firefox-60/ for more details.

Unfortunately, other browsers haven't followed suit, with sites like Hangouts still doing hacks (relinquishing the stream) when you click on the camera mute button (presumably to get the hardware light to go off on mute in Chrome), which causes annoying re-prompts in Firefox on unmute. Ironically, had they merely set `track.enabled = !muted.checked` as the spec intended, Hangouts would have worked as expected in Firefox.

I've opened [w3c/mediacapture-main#642](https://github.com/w3c/mediacapture-main/issues/642) to push the other browsers on this.

Happy to leave this open for discussion, but unless the permissions team wishes to pick this up, I don't think the media team has any plans for changes here.
Firefox's privacy guarantee is that once camera/mic indicators go away, they cannot come back unless users checked the box.

> We looked at keeping a reference to the microphone streams, but the microphone streams work best when they are closed out prior to playing audio prompts.

You should be able to work around this using the following:
```js
window.keepalive = stream.clone();
for (const track of window.keepalive.getTracks()) track.enabled = false;
```
Everything should behave as before, except you'll see gray (not red) camera/mic indicators in the URL bar when everything is off, and they'll turn red again instead of you being re-prompted when you request access anew.

See https://blog.mozilla.org/webrtc/better-privacy-on-camera-mute-in-firefox-60/ for more details.

Unfortunately, other browsers haven't followed suit, with sites like Hangouts still doing hacks (relinquishing the stream) when you click on the camera mute button (presumably to get the hardware light to go off on mute in Chrome - [crbug 642785](https://bugs.chromium.org/p/chromium/issues/detail?id=642785)), which causes annoying re-prompts in Firefox on unmute. Ironically, had they merely set `track.enabled = !muted.checked` as the spec intended, Hangouts would have worked as expected in Firefox.

I've opened [w3c/mediacapture-main#642](https://github.com/w3c/mediacapture-main/issues/642) to push the other browsers on this.

Happy to leave this open for discussion, but unless the permissions team wishes to pick this up, I don't think the media team has any plans for changes here.

Back to Bug 1596959 Comment 4