### Cause It turns out we only fire `"recording-device-stopped"` to front-end when removing an entire SourceListener [here](https://searchfox.org/mozilla-central/rev/5a66c4b4a41ab78a87c30c9db0d93c732c534402/dom/media/MediaManager.cpp#4219). For historical reasons, it may represent a camera + microphone *pair*, but only *when requested as a pair in `getUserMedia`*. Front-end listens to `"recording-device-stopped"` to terminate temporary permissions to device + kind based on track liveliness (an empty `message.rawID` means stop all, otherwise a specific device only). This is the disconnect. ### Effect Unprompted re-access to a camera or mic post-stop from a pair obtained in a joint gUM call, as long as the other half of the pair is kept live. STRs: In https://jan-ivar.github.io/dummy/gum_stop.html click `Start Both!` + `Stop cams!` + `Start cams!` = no re-prompt. Or, click `Start Both!` + `Stop mics!` + `Start mics!` = no re-prompt. ### Fix Remove the *pair* special case from SourceListener. It's arbitrary in the modern stack, which allows pairs of unrelated hardware anyway (e.g. BRIO cam + AirPod mic). . Well-tested. Simple fix. ### Why fix it? On first blush, the buggy behavior may seem desirable. Especially since some web conference sites asymmetrically stop camera on facemute to work around [crbug 642785](https://crbug.com/642785), but never stop the mic on micmute (so they can implement the *"Are you speaking? you should unmute"* feature). But it's highly unpredictable in practice: Several sites (Meet, WebEx) obtain camera and microphone separately, so it didn't happen there. Even if we got Meet to use a joint prompt, users might change their cams or mics independently anyway using the site's ⚙️ settings page, and then it wouldn't happen. But even if we made this reliable, it wouldn't work if the site stops both tracks, which some sites (MeetEcho?) appear to do on mute/unmute. We'd end up causing re-prompts in some sites but not others for seemingly comparably functionality. ### Use case But this does highlight a use-case: lurkers in medium-to-large meetings who spend most of their time facemuted and micmuted, only to unmute when called on to ask some question. A superior fix to address this use case directly would seem to be to significantly increase the grace period considered in bug 1693677 to minutes not seconds, for as long as the page is not navigated (then trim it down to seconds on navigation).
Bug 1395819 Comment 10 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
### Cause It turns out we only fire `"recording-device-stopped"` to front-end when removing an entire SourceListener [here](https://searchfox.org/mozilla-central/rev/5a66c4b4a41ab78a87c30c9db0d93c732c534402/dom/media/MediaManager.cpp#4219). For historical reasons, it may represent a camera + microphone *pair*, but only *when requested as a pair in `getUserMedia`*. Front-end listens to `"recording-device-stopped"` to terminate temporary permissions to device + kind based on track liveliness (an empty `message.rawID` means stop all, otherwise a specific device only). This is the disconnect. ### Effect Unprompted re-access to a camera or mic post-stop from a pair obtained in a joint gUM call, as long as the other half of the pair is kept live. STRs: In https://jan-ivar.github.io/dummy/gum_stop.html click `Start Both!` + `Stop cams!` + `Start cams!` = no re-prompt. Or, click `Start Both!` + `Stop mics!` + `Start mics!` = no re-prompt. ### Fix Remove the *pair* special case from SourceListener. It's arbitrary in the modern stack, which allows pairs of unrelated hardware anyway (e.g. BRIO cam + AirPod mic). . Well-tested. Simple fix. ### Why fix it? On first blush, the buggy behavior may seem desirable. Especially since some web conference sites asymmetrically stop camera on facemute to work around [crbug 642785](https://crbug.com/642785), but never stop the mic on micmute (so they can implement the *"Are you speaking? you should unmute"* feature). But it's highly unpredictable in practice: Several sites (Meet, WebEx) obtain camera and microphone separately, so it didn't happen there. Even if we got Meet to use a joint prompt, users might change their cams or mics independently anyway using the site's ⚙️ settings page, and then it wouldn't happen. But even if we made this reliable, it wouldn't work if the site stops both tracks, which some sites (MeetEcho?) appear to do on mute/unmute. We'd end up causing re-prompts in some sites but not others for seemingly comparably functionality. ### Use case But this does highlight a use-case: lurkers in medium-to-large meetings who spend most of their time facemuted and micmuted, only to unmute when called on to ask some question. A superior fix to address this use case directly would seem to be to significantly increase the grace period considered in bug 1693677 to minutes not seconds, for as long as the page is not navigated (then trim it down to seconds on navigation). I've filed this as bug 1697284.