Closed Bug 1908056 Opened 4 months ago Closed 2 months ago

Slack huddles are not working anymore with Firefox 132 (add legacy exception for Slack)

Categories

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

Firefox 128
Desktop
All
defect

Tracking

()

VERIFIED FIXED
133 Branch
Tracking Status
firefox-esr128 --- wontfix
firefox128 --- wontfix
firefox129 --- wontfix
firefox130 --- wontfix
firefox131 --- wontfix
firefox132 + verified
firefox133 + verified

People

(Reporter: u757425, Assigned: jib, NeedInfo)

References

()

Details

(Keywords: webcompat:contact-ready, webcompat:site-report)

User Story

platform:windows,mac,linux
impact:workflow-broken
configuration:general
affects:all
branch:release
diagnosis-team:video-conferencing

Attachments

(4 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0

Steps to reproduce:

  • On MacOS Sonoma 14.5 (23F79)
  • On Firefox 128.0 (64-bit)
  • With a clean Firefox profile
  • Log into Slack, start a Huddle

Actual results:

  • Slack can't access Microphone or Camera (see attached file).
  • Permission for Microphone was granted, permission for Camera was never asked.

Expected results:

  • Slack should have been able to get Microphone and Camera input.

Additional information:

  • It worked with Firefox 127.
  • I confirmed on a second MacBook.
  • I am able to use Google Meet normally.
  • Could this be linked to the getUserMedia changes introduced by 128 on MacOS?
Summary: Slack huddles are not working anymore with Firefox 128 → Slack huddles are not working anymore with Firefox 128 on MacOS

The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Audio/Video' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core

carrierlantern, are you able to try getting a regression window using https://mozilla.github.io/mozregression/?

Flags: needinfo?(laurent.lec)
QA Whiteboard: [qa-regression-triage]

So, this is interesting. I used mozregression to test several builds, and none worked.

The upgrade to 128 could therefore be a coincidence, and the bug could be on Slack's side.

I filed a bug report on their website. Let me know if there's anything else I can do to help.

Flags: needinfo?(laurent.lec)

When trying a call, up in the address bar, there's a little video icon that might be crossed out. I'm wondering if you somehow disabled camera access permissions. You might check that to see if you've somehow restricted access.

The severity field is not set for this bug.
:jib, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(jib)
Severity: -- → S3
Flags: needinfo?(jib)

I have reproduced this issue in Nightly v130.0a1, v125.0a1 and v115.0a1, while Nightly v110.0a1 is not supported (shows the error message: "We're very sorry, but your browser is not supported!"

The testing has been performed on a MacBook Air 2013 with MacOS 11.7.10. Considering the testing results, it seems that changes must have been made on the Slack side that caused this issue in Firefox on MacOS11. This does not reproduce in Windows 10 or 11. This does not seem to be a regression inside Firefox.

P.S. Huddles can not be tested using Mozregression. The test builds crash instantly when starting a Huddle.

Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → macOS
Hardware: Unspecified → Desktop

This is also affecting Windows

Severity: S3 → S2
User Story: (updated)
Priority: -- → P1
Summary: Slack huddles are not working anymore with Firefox 128 on MacOS → Slack huddles are not working anymore with Firefox 128
Duplicate of this bug: 1919501

ksenia, daniel - can you retest? We just tried this and it appeared to work in Nightly. Can you try release and nightly? Slack may have fixed something.
Note: linux isn't expected to work

Flags: needinfo?(kberezina)
Flags: needinfo?(dbodea)

I'm having an issue with the site detecting my camera.

edit: although they do appear to get access to it - I get prompted to approve camera access, then the camera light turns on briefly and then shuts off. No video frames are displayed.

Firefox release profile - https://share.firefox.dev/3BgGdYz

Some slack logging - they appear to be able to detect cameras but something goes wrong after they access it -

Sep-23 13:27:29.549 [FOCUS-EVENT] (E07DB2PSS3W) Main window focused gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.620 [CHECK-UNREADS] (E07DB2PSS3W) Checking unreads after window became focused gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.621 [CHECK-UNREADS] (E07DB2PSS3W) Not marking C07N6DR6N3Z because last_read >= latest && channel is read gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.635 [DEVICE-PERMISSIONS-MA] camera permissions granted: false gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.636 [DEVICE-PERMISSIONS-MA] camera permissions granted: false gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.636 [DEVICES] (E07DB2PSS3W) DeviceManager::getMediaAccessStatus camera electron API available: false and status: not-determined gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.636 [HUDDLE-CLIENT-MIDDLEW] client-huddles-middleware user toggling ON video gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.637 [DEVICES] (E07DB2PSS3W) Camera quality settings changed: 450x450@25fps 500kbps gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.637 [HUDDLE-SDK] (E07DB2PSS3W) API/DefaultAudioVideoFacade/aef564af-9971-4178-9f70-0eb5170e2713/6cbd30b8-eda2-2d6f-445c-e01e12dc306b/chooseVideoInputQuality {"width":450,"height":450,"frameRate":25} gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.637 [HUDDLE-SDK] (E07DB2PSS3W) video send has ideal max bandwidth 500 kbps gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.637 [HUDDLE-SDK] (E07DB2PSS3W) API/DefaultAudioVideoFacade/aef564af-9971-4178-9f70-0eb5170e2713/6cbd30b8-eda2-2d6f-445c-e01e12dc306b/setVideoMaxBandwidthKbps 500 gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.637 [HUDDLE-SDK] (E07DB2PSS3W) API/DefaultDeviceController/setDeviceLabelTrigger gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.638 [HUDDLE-SDK] (E07DB2PSS3W) API/DefaultDeviceController/listVideoInputDevices false -> [{"deviceId":"wIZ7M/JV4oRAZWPd93dK6i2hejz5CY66sYOufMIS1WM=","kind":"videoinput","label":"Logitech Webcam C930e","groupId":"qnHM57ToIEej/3FnOIvqKTUrF8gRhyty7I47wfnS40g="}] gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.638 [HUDDLE-SDK] (E07DB2PSS3W) API/DefaultAudioVideoFacade/aef564af-9971-4178-9f70-0eb5170e2713/6cbd30b8-eda2-2d6f-445c-e01e12dc306b/listVideoInputDevices false -> [{"deviceId":"wIZ7M/JV4oRAZWPd93dK6i2hejz5CY66sYOufMIS1WM=","kind":"videoinput","label":"Logitech Webcam C930e","groupId":"qnHM57ToIEej/3FnOIvqKTUrF8gRhyty7I47wfnS40g="}] gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.638 [DEVICES] (E07DB2PSS3W) V2 devices found. Updating device store gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.640 [DEVICE-PERMISSIONS-MA] camera permissions granted: false 2 gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.640 [DEVICES] (E07DB2PSS3W) DeviceManager::getMediaAccessStatus camera electron API available: false and status: not-determined gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.640 [HUDDLE-DISPATCHER] (E07DB2PSS3W) Self camera turned on gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.641 [HUDDLE-SDK] (E07DB2PSS3W) maybeEnableSelfCamera:: enabling camera function executed gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.663 [UFM] (E07DB2PSS3W) requesting E07DB2PSS3W: (1) gantry-v2-shared.d80086337ab308929c60.min.js:114:167007
Sep-23 13:27:29.664 [UFM] (E07DB2PSS3W) received E07DB2PSS3W: (1)

Note this repos on mac as well. Once camera access is granted, the little huddle app resizes video but fails to collect any frames from the camera. Jib thinks this might be related to Bug 1286945 - Offer downscaled resolutions and decimated framerates in getUserMedia.

OS: macOS → All

(In reply to Jim Mathies [:jimm] from comment #12)

Firefox release profile - https://share.firefox.dev/3BgGdYz

(In reply to Jim Mathies [:jimm] from comment #14)

Note this repos on mac as well. Once camera access is granted, the little huddle app resizes video but fails to collect any frames from the camera. Jib thinks this might be related to Bug 1286945 - Offer downscaled resolutions and decimated framerates in getUserMedia.

Note, the profile does not contain any request for camera so does not point towards bug 1286945.

Workaround: If others can confirm this works as well that would be great:

  1. In about:config, set media.devices.enumerate.legacy.enabled to true
  2. Open slack in a new tab
  3. Start a Huddle
  4. If Firefox prompts for microphone permission, you MUST check ✅ Remember for all microphones and Allow
  5. Unmute camera
  6. If Firefox prompts for camera, allow. Otherwise, refresh the page, and repeat steps 5 and 6.

Hypothesis:

  • Slack's application code incorrectly assumes the only acceptable permission is persisted permission in a browser where this reveals ALL labels in enumerateDevices() on pageload. Such behavior now violates the spec (see crbug 40138537). Firefox's behavior is to spec.

Evidence of this in https://a.slack-edge.com/bv1-13-br/client-boot.88801f3e5d47f5483971.min.js?cacheKey=gantry-1727110053:

const S = (yield navigator.mediaDevices.enumerateDevices()).filter(K => K.kind === W),
V = S.length > 0 &&
S.some(K => K.label.trim() !== '');
R.updatePermissionsState(U, V ? n.eJ.Granted : n.eJ.NotDetermined)

...and

G.logger.info('Refreshing all permissions');
try {
  yield navigator.mediaDevices.enumerateDevices(),
  yield G.refreshPermissions(c.mT.MICROPHONE),
  yield G.refreshPermissions(c.mT.CAMERA),
  yield G.refreshPermissions(c.mT.SCREEN)
} catch (W) {
  G.logger.warn('An error occurred while refreshing device permissions', W)
}

Device exposure is no longer tied to permission in the spec. So the application code is broken and will not work in Firefox or Safari. Based on comment 6, this appears to be a Slack regression.

getUserMedia includes a permission prompt, so attempts to resolve permission ahead of calling it (or even refusing to call it) should be unnecessary and seem counterproductive.

To clarify, this is broken even with legacy mode on: Firefox users shouldn't have to ✅ Remember for all microphones to use Slack.

Firefox 132 (which turns legacy mode off) supports permissions.query({name: "camera" | "microphone"}) (bug 1916993) which can be used to determine permission state, if that helps.

Sounds like this needs some outreach. They've shipped something that is only compatible with one browser (Chrome).

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #9)

ksenia, daniel - can you retest? We just tried this and it appeared to work in Nightly. Can you try release and nightly? Slack may have fixed something.
Note: linux isn't expected to work

I can still reproduce this just the same with Nightly v132.0a1 from 2024-09-25 in a call between MacOS 11 and Windows 10. The camera and microphone are not recognized on MacOS inside a Huddle.

MacOS: It would appear that the reproduction is somewhat related to the input/output devices used. Initially, it seemed to be MacOS specific as the integrated speakers, camera and microphone were unrecognized inside a Huddle, furthermore, connecting double-jack headphones still would not let the Huddle recognize the connected devices. When connecting USB headphones, the devices would finally be recognized (except the integrated camera). In other unexpected situations, MacOS will still show behaviors where neither of the input/output devices are recognized by Slack (including the USB headphones).

Windows: Something similar can be seen in Windows (desktop) if not the same: Initially, I tried to connect some speakers, a Logitech Webcam and its integrated microphone, but it would not recognize them. Then I connected some USB headphones and the input devices were finally recognized and working.

It would seem that the whole problem is related to how the input/output devices are managed/permited by slack web. I have also noticed that some pop-up windows were blocked by Nightly when creating a new window for the Huddle; I don't know if this is related or not.

I can also confirm that while using Release v130.0.1, neither of the different input/output devices were recognized inside a Huddle.

I couldn't determine clear test results as they were quite inconsistent. If you think that further testing is needed, please let me know of the direction that I should take / specific things I should check. Thank you!

Flags: needinfo?(dbodea) → needinfo?(rjesup)

I had somewhat similar behaviour as Daniel on MacOS > Windows call. There seems to be a pattern - when using the integrated mic, it doesn't get recognized initially (neither does camera), but when connecting bluetooth headphones, both mics (bluetooth and integrated) and camera get recognized. Furthermore, after disconnecting bluetooth headphones, the integrated mic and camera remains recognized.

For the first call I used integrated microphone. When making a call, got asked for a permission to use the microphone and allowed it, but the call recipient couldn't hear me. Also tried to enable the video, with no luck. Both mic and camera were not recognized in the call settings.

For the second call, I connected my bluetooth headphones, reloaded the page and made a call again, got asked for a permission to use the mic, recipient could hear and see me, both bluetooth mic and camera become recognized (in the settings could see the integrated mic as an option too).

For the third call I disconnected bluetooth headphones, reloaded the page, made a call and tried using the integrated mic and it was recognized, so did the camera.

For the forth call I revoked permissions, opened a new tab and made a call with the integrated mic, neither mic or camera were recognized again.

Flags: needinfo?(kberezina)

Per comment 16, we understand what they're doing wrong. We're operating to spec; their code shouldn't work except in Chrome/Edge - not in firefox or Safari. NI'ing jimm to remind him to do or get someone to do (Karen?) outreach per comment 18

Flags: needinfo?(rjesup) → needinfo?(jmathies)

Daniel and Ksenia, have you tried comment 16? It explains how to get slack into a state where it recognizes it has persistent microphone permission, which then unlocks camera discovery by their app logic. This should explain why some report it works and others report it doesn't.

This seems a local problem of device discovery, which happens ahead of calling, so network and peer system shouldn't matter.

Unfortunately, 132 compounds the problem by turning off legacy mode. I'll provide a patch here to add an exception for slack. This won't totally fix the problem but should reduce it to comment 17 (people who didn't check ✅ Remember for all microphones).

Flags: needinfo?(kberezina)
Flags: needinfo?(dbodea)
Assignee: nobody → jib
Status: NEW → ASSIGNED

I believe Slack is using https://github.com/aws/amazon-chime-sdk-js (https://github.com/webcompat/web-bugs/issues/82623#issuecomment-1897894395). If we allowlist slack won't we potentially have the same problem on other sites using Amazon chime?

Should we reach out to Amazon to try to get this sorted upstream?

Flags: needinfo?(jib)

Are you sure? I'm not seeing any signs of the comment 16 code upstream. Maybe Slack handles permissions in a layer above chime?

Flags: needinfo?(jib) → needinfo?(jmuizelaar)

If we allowlist slack won't we potentially have the same problem on other sites using Amazon chime?

The patch adds an allowlist pref we can use to make a case by case determination. I'll try to get it uplifted to 132.

I suggest we exempt slack at least until they've fixed this Firefox regression which clearly predates 132 — ✅ Remember for all microphones + page reload shouldn't be needed to find cameras — to uncomplicate the question of cause.

Keywords: leave-open
Pushed by jbruaroey@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4b4307c3d73d Add media.devices.enumerate.legacy.allowlist exception for slack. r=dbaker
Pushed by jbruaroey@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2a113bd8a15d Add media.devices.enumerate.legacy.allowlist exception for slack. r=dbaker https://hg.mozilla.org/integration/autoland/rev/8148172860d2 Split out separate test_enumerateDevices_legacy_allowlist.html test. r=dbaker

[Tracking Requested - why for this release]: See comment 26.

Flags: needinfo?(jib)

Comment on attachment 9428626 [details]
Bug 1908056 - Add media.devices.enumerate.legacy.allowlist exception for slack. r?dbaker

Beta/Release Uplift Approval Request

  • User impact if declined: Slack huddles won't work. Specifically, the workaround to check "✅ Remember for all microphones" + reloading the page to get it working will stop working in 132.

Getting the legacy allowlist pref uplifted to 132 also gives us more options to handle any other potential website fallout from 132 dropping the legacy (more permissive) version of enumerateDevices(), should there be any.

  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This adds an allowlist pref for an existing boolean pref. Reuses existing allowlist parsing code from bug 1876865. Tested.

Both patches should be uplifted

  • String changes made/needed:
  • Is Android affected?: No
Attachment #9428626 - Flags: approval-mozilla-beta?
Blocks: 1923194

Closing as fixed to track the legacy exception landed for Slack. Filed bug 1923194 to document that Slack huddles still aren't working even with this fix (work for that is needed by Slack).

No longer blocks: 1923194
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Summary: Slack huddles are not working anymore with Firefox 128 → Slack huddles are not working anymore with Firefox 132 (add legacy exception for Slack)
No longer blocks: webrtc-triage

Comment on attachment 9428626 [details]
Bug 1908056 - Add media.devices.enumerate.legacy.allowlist exception for slack. r?dbaker

Approved for 132.0b5.

Attachment #9428626 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9428941 - Flags: approval-mozilla-beta+

Are we going to want this on Release/ESR128 also? Please nominate if so.

Flags: needinfo?(jib)
Flags: in-testsuite+
Target Milestone: --- → 133 Branch

Are we going to want this on Release/ESR128 also? Please nominate if so.

No need since legacy mode is the default in 131 and earlier.

Flags: needinfo?(jib)
Flags: qe-verify+
QA Whiteboard: [qa-regression-triage] → [qa-regression-triage][qa-triaged]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #22)

Daniel and Ksenia, have you tried comment 16? It explains how to get slack into a state where it recognizes it has persistent microphone permission, which then unlocks camera discovery by their app logic. This should explain why some report it works and others report it doesn't.

This seems a local problem of device discovery, which happens ahead of calling, so network and peer system shouldn't matter.

Unfortunately, 132 compounds the problem by turning off legacy mode. I'll provide a patch here to add an exception for slack. This won't totally fix the problem but should reduce it to comment 17 (people who didn't check ✅ Remember for all microphones).

Yes, I can confirm the information in comment 22. If I use the steps from comment 16 and a page refresh I succeed in connecting with my microphone and camera in a Huddle:

  1. In about:config, set media.devices.enumerate.legacy.enabled to true
  2. Open slack in a new tab
  3. Start a Huddle
  4. If Firefox prompts for microphone permission, you MUST check ✅ Remember for all microphones and Allow
  5. Refresh the tab.
    Actual: The microphone finally starts working.
  6. Unmute camera
    Actual: Webcam stream finally works.

Conclusion:

  1. This fix has been tested with Nightly v133 (2024-10-06 and 2024-10-14), Beta v133.0b3 and v132.0b7.
  2. Since the fix was only uplifted to Beta v132.0b5, I don't understand why it works on Beta v132.0b3 (where media.devices.enumerate.legacy.allowlist is not set as "slack.com,*.slack.com").
  3. Unfortunately, this can't be considered a final fix since the user needs to set preconditions for the Huddle call to work correctly (flipping the media.devices.enumerate.legacy.enabled pref to true, checking the "Remember for all microphones" on the permission doorhanger and refresh the page).

@:Jib: This report appears partially fixed. How should we address it forward? Should we close this one and open another? Thank you!

Flags: needinfo?(dbodea) → needinfo?(jib)
  1. Unfortunately, this can't be considered a final fix since the user needs to set preconditions for the Huddle call to work correctly (flipping the media.devices.enumerate.legacy.enabled pref to true, checking the "Remember for all microphones" on the permission doorhanger and refresh the page).

Once media.devices.enumerate.legacy.allowlist = "slack.com,*.slack.com" is in place, the media.devices.enumerate.legacy.enabled = true precondition should no longer be needed for slack. Sorry I should have clarified that. Can you retest?

The remaining preconditions (checking the "Remember for all microphones" on the permission doorhanger and refresh the page) is a slack side issue tracked in bug 1923194 (per comment 34).

Blocks: 1923194
Flags: needinfo?(jib)
No longer blocks: 1923194
See Also: → 923194
See Also: 9231941923194

I can confirm that the Slack Huddles work in Beta v132.0 (RC) and Nightly v133.0a1 if the user checks the Remember for all microphones checkbox from the permission doorhanger and refreshes the webpage. Considering bug 1923194 addresses the remaining shortcomings of this report, I will close this one as verified. Thank you!

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: