Bugzilla

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #2)
> I think 2 is the best solution, even short-term. To sell it, I wouldn't even gate this on removing `webrtcUI.activePerms`. Merely:
> 
>   1. Add an ALLOW, SCOPE_TEMPORARY in [activateDevicePerm](https://searchfox.org/mozilla-central/rev/aa9a7136835deb0eeba00c62bb50a4a0e2cdea2d/browser/actors/WebRTCParent.jsm#323) without grace period, using the same key we use for grace periods
> 2. Modify [deactivateDevicePerm](https://searchfox.org/mozilla-central/rev/aa9a7136835deb0eeba00c62bb50a4a0e2cdea2d/browser/actors/WebRTCParent.jsm#340) to change it to an expiring one. If not found, then no grace period.
> 
> Adding a temporary grant permission at the point of grant, and then converting it to a grace period on stop, accomplishes two things:
> 
>   - Fix this bug, by giving clearPermissionsAndStopSharing  something to clear, leaving nothing to be converted to grace periods
>   - Perhaps map more closely to the user-observable model

If we don't want to change the current permission behavior with iframes we need to key by device type, device ID **and** outer window ID, as `activePerms` does. I've refactored `webRTCParent` so it uses SitePermissions instead of the `activePerms` map, and sets permissions like `camera^myCameraID^12` where 12 is the outer window ID. While I'm not a big fan of adding yet another key, SitePermissions and the permission panel can handle it already.
This runs mostly fine on tests. However, I've discovered that `webrt:StopRecording` isn't called for the error case. Specifically in this test: https://searchfox.org/mozilla-central/rev/1a47a74bd5ba89f2474aa27c40bd478e853f3276/browser/base/content/test/webrtc/browser_devices_get_user_media_queue_request.js#122,145
This means `deactivateDevicePerm` isn't called for this case and we end up with a lingering permission.

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #2)
> I think 2 is the best solution, even short-term. To sell it, I wouldn't even gate this on removing `webrtcUI.activePerms`. Merely:
> 
>   1. Add an ALLOW, SCOPE_TEMPORARY in [activateDevicePerm](https://searchfox.org/mozilla-central/rev/aa9a7136835deb0eeba00c62bb50a4a0e2cdea2d/browser/actors/WebRTCParent.jsm#323) without grace period, using the same key we use for grace periods
> 2. Modify [deactivateDevicePerm](https://searchfox.org/mozilla-central/rev/aa9a7136835deb0eeba00c62bb50a4a0e2cdea2d/browser/actors/WebRTCParent.jsm#340) to change it to an expiring one. If not found, then no grace period.
> 
> Adding a temporary grant permission at the point of grant, and then converting it to a grace period on stop, accomplishes two things:
> 
>   - Fix this bug, by giving clearPermissionsAndStopSharing  something to clear, leaving nothing to be converted to grace periods
>   - Perhaps map more closely to the user-observable model

If we don't want to change the current permission behavior with iframes we need to key by device type, device ID **and** outer window ID, as `activePerms` does. I've refactored `webRTCParent` so it uses SitePermissions instead of the `activePerms` map, and sets permissions like `camera^myCameraID^12` where 12 is the outer window ID. While I'm not a big fan of adding yet another key, SitePermissions and the permission panel can handle it already.
This runs mostly fine on tests. However, I've discovered that `webrt:StopRecording` isn't called for the error case. Specifically in this test: https://searchfox.org/mozilla-central/rev/1a47a74bd5ba89f2474aa27c40bd478e853f3276/browser/base/content/test/webrtc/browser_devices_get_user_media_queue_request.js#122,145
This means `deactivateDevicePerm` isn't called for the error case and we end up with a lingering permission.