1771029 - Google Meet auto-switches when I put on AirPods/headset in Chrome but not in Firefox

Status: NEW

(Core :: WebRTC: Audio/Video, defect, P3)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: ConnectedToAirpods.png

This was reported in https://twitter.com/matthew_d_green/status/1527687593965518849, and I believe I know what's going on.

We've identified a situation where Google Meet works differently in Firefox vs Chrome:

1. The user joins a meeting without their AirPods on
2. then they open the case and put them on

In this situation, Meet auto-switches to the AirPods in Chrome (see toast message in the attached screenshot), but not in Firefox.

We suspect Meet holds off in Firefox because it might trigger a permission prompt, because by default we give per-device permissions in Firefox. An unprompted permission prompt could surprise a percentage of users, who might click Block, ruining Meet's access to the AirPods in the current tab, which is a legitimate concern.

This seems like a good use case to finally implement bug 1609427. With that API, Meet could check that it has permission to the AirPods without inducing a prompt:

const perm = await navigator.permissions.query({name: "camera", deviceId: headsetDeviceId});
if (perm.state == "granted") {
  proceedToSwitchToHeadset(headsetDeviceId);
}

This would fix it for the significant population of users who have already checked ☑ Remember this decision for Meet.

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: SwitchToAirpodsWhereby.png

This would fix it for the significant population of users who have already checked ☑ Remember this decision for Meet.

To solve it for the remaining population would require either

1. a change to our permission handling to never Temporarily Block permission to secondary devices when a primary device has already been granted. We could detect these cases and change the Block button to Not Now in those cases, or
2. A redesign on Google Meet's part to prompt the user like Whereby.com does (see attached screenshot).

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

It's worth noting that doing step 1 in comment 1 might fix this for all users, without the need to fix bug 1609427, provided Meet is comfortable with triggering unprompted permission prompts once they're less harmful to their permission state (they might still want to suppress them, which would be an application decision, but we might hope they wouldn't to help parity with Chrome where switching implicitly happens without a prompt).

Comment 3

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

1. a change to our permission handling to never Temporarily Block permission to secondary devices when a primary device has already been granted. We could detect these cases and change the Block button to Not Now in those cases,

Bug 1609578 would also be fixed by this. I've outlined a concrete proposal there.

Comment 4

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

There are two potential solutions here, but no way to add dependencies on one OR the other, so I'm marking it dependent on both for now.

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Bug 1609578 has been fixed in 106, which should unblock this, so I'm removing the other dependency.

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Here's the state of Firefox's improvements for sites offering users to auto-switch devices:

• Firefox 89 added a 60-minute grace period to per-camera/mic permissions on desktop
• Firefox 101 allows capture from multiple microphones
• Firefox 106 replaces the "Block" foot-gun with "Not Now" in permission prompts specifically when switching devices on desktop (bug 1609578)

Together with the Meet team, the actions identified on the web application side to benefit from these new features were:

1. Avoid users being left muted or without a camera when switching devices under ⚙️ and choosing "Not Now"
   • by reverting to the previous device in response to permission failure, which is possible as of 106
2. Improve microphone switching flow without stopping audio
   • by opening up new capture to determine if it succeeds before stopping tracks, which is possible as of 101
3. Auto-switch Firefox users who put on headsets without risk of permission block or dropping audio on "Not Now"
   • which is possible as of 106