Slack huddles are not working anymore with Firefox 132 (add legacy exception for Slack)
Categories
(Core :: WebRTC: Audio/Video, defect, P1)
Tracking
()
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)
398.41 KB,
image/png
|
Details | |
148.89 KB,
image/png
|
Details | |
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
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?
Comment 1•4 months ago
|
||
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.
Updated•4 months ago
|
Comment 2•4 months ago
|
||
carrierlantern, are you able to try getting a regression window using https://mozilla.github.io/mozregression/?
Updated•4 months ago
|
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.
Comment 4•4 months ago
|
||
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.
Comment 5•4 months ago
|
||
The severity field is not set for this bug.
:jib, could you have a look please?
For more information, please visit BugBot documentation.
Assignee | ||
Updated•4 months ago
|
Comment 6•4 months ago
|
||
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.
Comment 7•2 months ago
|
||
This is also affecting Windows
Comment 9•2 months ago
|
||
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
Comment 10•2 months ago
•
|
||
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.
Comment 11•2 months ago
|
||
Comment 12•2 months ago
|
||
Firefox release profile - https://share.firefox.dev/3BgGdYz
Comment 13•2 months ago
•
|
||
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)
Updated•2 months ago
|
Comment 14•2 months ago
|
||
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.
Updated•2 months ago
|
Comment 15•2 months ago
|
||
(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.
Assignee | ||
Comment 16•2 months ago
|
||
Workaround: If others can confirm this works as well that would be great:
- In
about:config
, setmedia.devices.enumerate.legacy.enabled
totrue
- Open slack in a new tab
- Start a Huddle
- If Firefox prompts for microphone permission, you MUST check
✅ Remember for all microphones
and Allow - Unmute camera
- 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.
Assignee | ||
Comment 17•2 months ago
•
|
||
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.
Comment 18•2 months ago
|
||
Sounds like this needs some outreach. They've shipped something that is only compatible with one browser (Chrome).
Comment 19•2 months ago
|
||
(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!
Comment 20•2 months ago
•
|
||
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.
Comment 21•2 months ago
|
||
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
Updated•2 months ago
|
Assignee | ||
Comment 22•2 months ago
|
||
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
).
Assignee | ||
Comment 23•2 months ago
|
||
Updated•2 months ago
|
Comment 24•2 months ago
|
||
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?
Assignee | ||
Comment 25•2 months ago
|
||
Are you sure? I'm not seeing any signs of the comment 16 code upstream. Maybe Slack handles permissions in a layer above chime?
Assignee | ||
Comment 26•2 months ago
|
||
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.
Assignee | ||
Updated•2 months ago
|
Comment 27•2 months ago
|
||
Comment 28•2 months ago
|
||
Backed out for causing mda failures @ test_enumerateDevices_legacy.html
Backout link: https://hg.mozilla.org/integration/autoland/rev/89eb9c53d815d3717f912691017ef957fe696c76
Assignee | ||
Comment 29•2 months ago
|
||
Depends on D224367
Comment 30•2 months ago
|
||
Comment 31•2 months ago
|
||
bugherder |
Assignee | ||
Comment 32•2 months ago
|
||
[Tracking Requested - why for this release]: See comment 26.
Assignee | ||
Comment 33•2 months ago
|
||
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
Assignee | ||
Comment 34•2 months ago
|
||
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).
Assignee | ||
Updated•2 months ago
|
Updated•2 months ago
|
Comment 35•2 months ago
|
||
Comment on attachment 9428626 [details]
Bug 1908056 - Add media.devices.enumerate.legacy.allowlist exception for slack. r?dbaker
Approved for 132.0b5.
Updated•2 months ago
|
Comment 36•2 months ago
|
||
Are we going to want this on Release/ESR128 also? Please nominate if so.
Comment 37•2 months ago
|
||
uplift |
Updated•2 months ago
|
Assignee | ||
Comment 38•2 months ago
|
||
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.
Updated•2 months ago
|
Updated•1 month ago
|
Updated•1 month ago
|
Comment 39•1 month ago
|
||
(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:
- In about:config, set media.devices.enumerate.legacy.enabled to true
- Open slack in a new tab
- Start a Huddle
- If Firefox prompts for microphone permission, you MUST check ✅ Remember for all microphones and Allow
- Refresh the tab.
Actual: The microphone finally starts working. - Unmute camera
Actual: Webcam stream finally works.
Conclusion:
- This fix has been tested with Nightly v133 (2024-10-06 and 2024-10-14), Beta v133.0b3 and v132.0b7.
- 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").
- 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!
Assignee | ||
Comment 40•1 month ago
|
||
- 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).
Assignee | ||
Updated•1 month ago
|
Assignee | ||
Updated•1 month ago
|
Comment 41•1 month ago
|
||
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!
Description
•