Open
Bug 1502324
Opened 6 years ago
Updated 2 years ago
[Intermittent] [mac 10.14] Webcam doesn't work properly on some sites even if the permission is granted from the system
Categories
(Core :: WebRTC: Audio/Video, defect, P2)
Tracking
()
NEW
People
(Reporter: obotisan, Assigned: haik)
References
Details
Attachments
(7 files)
Potential nsIPrompt alert for when the browser doesn't have OS access to camera/mic
[Affected versions]:
- Beta 64.0b3
- Nightly 65.0a1.
[Affected platforms]:
- mac10.14
[Prerequisites]:
Run the command "tccutil reset All" in the terminal to make sure that all the application device permissions are cleared.
[Steps to reproduce]:
1. Go to https://talky.io.
2. Make a call and grant permission both to the browser doorhanger and OS prompt.
3. Go to System Preferences -> Security & Privacy -> Privacy -> uncheck the box for Firefox in the Camera section.
4. Quit Firefox and restarted.
5. Go back to https://talky.io and grant permission for the camera from the doorhanger. - the call goes through, but there is an error shown instead of the video from the webcam.
6. Repeat step 3 and check the box for Firefox in Camera section. Quit and restart Firefox.
7. Go back to https://talky.io and grant permission for the camera from the doorhanger.
[Expected result]:
- The call goes through and the webcam is working properly.
[Actual result]:
- The error "Oh no! We can't access your camera/microphone. Unknown error occurred" is displayed on the screen.
[Regression]:
- I am not sure that this is a regression, but considering the fact that the bug is intermittent I am not sure how I could find it.
[Additional Notes]:
- It might be an issue related to macOS.
|
||
Comment 1•6 years ago
|
||
Haik, can you take a look at this?
Rank: 15
Flags: needinfo?(haftandilian)
Priority: -- → P2
|
Assignee | |
Updated•6 years ago
|
Assignee: nobody → haftandilian
Flags: needinfo?(haftandilian)
Priority: P2 → P1
|
||
Comment 2•6 years ago
|
||
This is new with Mojave, so not a regression. Sounds like bug 1494172.
|
|
||
Comment 3•6 years ago
|
||
We probably need a short-term fix for uplift to 64, so blocking on bug 1494172 might not work?
Would it be possible to detect we're blocked and avoid the permission prompt altogether in this case, and reject w/NotFoundError?
For users who did this intentionally, this respects the user's previous decision to not allow camera/mic access in Firefox, and avoids the futile prompt noise.
Users who did this accidentally would remain stuck without instructions on how to get unstuck (bug 1494172).
Would that be an acceptable interim solution?
Flags: needinfo?(haftandilian)
|
Reporter | |
Comment 4•6 years ago
|
||
I found something that could help. On this site, https://talky.io, the error "Oh no! We can't access your camera/microphone. Unknown error occurred" is displayed even if only the microphone is disabled and the webcam is enabled.
I am guessing that in some circumstances the microphone is being disabled at the same time with the microphone, but it's not being enabled again when the microphone is.
|
|
Assignee | |
Comment 5•6 years ago
|
||
I'll be working on this today.
(In reply to Oana Botisan from comment #0)
> [Steps to reproduce]:
> 1. Go to https://talky.io.
> 2. Make a call and grant permission both to the browser doorhanger and OS
> prompt.
> 3. Go to System Preferences -> Security & Privacy -> Privacy -> uncheck the
> box for Firefox in the Camera section.
> 4. Quit Firefox and restarted.
> 5. Go back to https://talky.io and grant permission for the camera from the
> doorhanger. - the call goes through, but there is an error shown instead of
> the video from the webcam.
I'll debug to see what state the OS is reporting the camera to be in (allowed/not-allowed/undetermined). Apple's docs state that the permission prompt will not be shown again if the user chooses to deny, but I don't know what is meant to happen in this case. TBD if is this is a bug.
> 6. Repeat step 3 and check the box for Firefox in Camera section. Quit and
> restart Firefox.
> 7. Go back to https://talky.io and grant permission for the camera from the
> doorhanger.
>
> [Expected result]:
> - The call goes through and the webcam is working properly.
>
> [Actual result]:
> - The error "Oh no! We can't access your camera/microphone. Unknown error
> occurred" is displayed on the screen.
If after step 7, the camera is not accessible, this does sound like a bug. The steps were check the box for Firefox in the Camera section, restart firefox, use camera.
Flags: needinfo?(haftandilian)
|
|
Assignee | |
Comment 6•6 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #3)
> We probably need a short-term fix for uplift to 64, so blocking on bug
> 1494172 might not work?
Agree. I don't think we should block on bug 1494172 if we can avoid it. I'll work on understanding the root cause and then we can make a better decision about how to fix this.
|
|
Assignee | |
Comment 7•6 years ago
|
||
Testing on Nightly on Mojave with talky.io, I have not been able to reproduce the problem where the access in the browser is not consistent with what is displayed in the "Privacy & Security" settings. I always restart the browser after changing the settings in Privacy & Security (as instructed by the OS prompts.)
I'm still testing, but so far the prompts/access are working as expected. The situation where we don't have OS access and an error is displayed on the site should be improved by bug 1494172 with a browser dialog. In the meantime, it looks like it would be pretty straightforward to add an nsIPrompt alert when this situations happens. I'll attach a screenshot.
|
|
Assignee | |
Comment 8•6 years ago
|
||
Potential nsIPrompt alert for when the browser doesn't have OS access to the camera/mic, but the user has granted the site permission.
|
|
Assignee | |
Comment 9•6 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #3)
> We probably need a short-term fix for uplift to 64, so blocking on bug
> 1494172 might not work?
>
> Would it be possible to detect we're blocked and avoid the permission prompt
> altogether in this case, and reject w/NotFoundError?
i.e. to avoid trigger the site permission prompt when we know the browser doesn't have OS access.
It would be possible, but I think skipping the permission prompt would be inconsistent/confusing for users. The site would end up displaying the same error so I think there'd be little benefit.
Flags: needinfo?(jib)
|
|
||
Comment 10•6 years ago
|
||
(In reply to Haik Aftandilian [:haik] from comment #5)
> If after step 7, the camera is not accessible, this does sound like a bug.
> The steps were check the box for Firefox in the Camera section, restart
> firefox, use camera.
Ah, I misread the STRs. So the bug filed here is it doesn't work to turn it back on in the OS. Agree that is a high priority bug.
My comments were about something else. I've filed bug 1502967 for that, and will move discussion there. Sorry for the confusion.
|
||
Comment 11•6 years ago
|
||
I think manually messing application permissions makes this case highly unlikely to happen. Plus the fact that this is a Mojave specific issue and not a regression I don't see this as a P1.
We should still continue to check if we can handle this better, but it is not a release blocker.
Priority: P1 → P2
|
|
||
Comment 12•6 years ago
|
||
(In reply to Oana Botisan from comment #4)
> I am guessing that in some circumstances the microphone is being disabled
> at the same time with the microphone, but it's not being enabled again when
> the microphone is.
To rule out other errors caused by microphone problems, can you repro with a different site that shows the error code?
E.g. https://jsfiddle.net/jib1/pz5pynyf/
Flags: needinfo?(jib) → needinfo?(oana.botisan)
|
|
||
Comment 13•6 years ago
|
||
E.g. when I try the fiddle in comment 12 repeatedly, I occasionally see:
MediaStreamError { name: "AbortError", message: "The operation was aborted.", constraint: "", stack: "" }
|
|
Assignee | |
Comment 14•6 years ago
|
||
FYI, on Nightly, we have bug 1501745 which affects how the prompts work on jsfiddle.net.
|
|
Reporter | |
Comment 15•6 years ago
|
||
I tried to find out the frequency that this bug is reproducing. I managed to reproduce it 1 in about 25-30 tries and got about two different results.
When I opened the macbook for the first time (all the devices permission were cleared before the computer was closed) and did the steps, but on the last step I used https://jsfiddle.net/jib1/r60bzmrs/, instead on talky.io. (I did this in order to eliminate the issue I mentioned in comment 4).
What happened was that the doorhanger wasn't triggered and the webcam was automatically disabled. You can see the result in the attached file.
Flags: needinfo?(oana.botisan)
|
|
Reporter | |
Comment 16•6 years ago
|
||
One out of 15 tries I got the result you can see in the attached file. The image didn't load no matter how much I waited. But this issue could be related to the test page, only after the page was refresh everything started to glitch. You can see that behaviour in the mov. file attached to the next comment.
|
|
Reporter | |
Comment 17•6 years ago
|
||
I think this is either a test page issue or another issue all together. I don't think it's related to this bug.
|
|
||
Comment 18•6 years ago
|
||
(In reply to Haik Aftandilian [:haik] from comment #14)
> FYI, on Nightly, we have bug 1501745 which affects how the prompts work on
> jsfiddle.net.
FWIW you can circumvent bug 1501745 by loading the result-iframe content directly: https://fiddle.jshell.net/jib1/pz5pynyf/show/light/
|
|
||
Comment 19•6 years ago
|
||
(In reply to Oana Botisan from comment #15)
> What happened was that the doorhanger wasn't triggered and the webcam was
> automatically disabled. You can see the result in the attached file.
This sounds like bug 1501745 indeed. Try the url in comment 18 and it should take you a bit further.
Flags: needinfo?(oana.botisan)
|
|
Reporter | |
Comment 20•6 years ago
|
||
I did a few tests using the link from comment 18.
I did notice one thing. The macbook was on sleep mode for about an hour and a half and then when I tried with that link the issue reproduced again.
Flags: needinfo?(oana.botisan)
|
|
Reporter | |
Comment 21•6 years ago
|
||
An another thing happened. When I tried to reproduce the issue again, for some reason the webcam system permission wasn't activated. The video was working, but the permission wasn't granted from the system. Please look at the attached image to see the issue.
|
|
Reporter | |
Comment 22•6 years ago
|
||
The issue mentioned in comment 21 was reproducing no matter how much I refreshed the page or open the site again. I had to quit Firefox and reopen it to make it work again.
Also, I should mention that all these test were made on beta 64.0b4 and every time I changed the system permissions, I restarted the browser.
|
|
||
Comment 23•6 years ago
|
||
(In reply to Oana Botisan from comment #20)
> Created attachment 9021162 [details]
> Screenshot 2018-10-30 at 14.12.07.png
It would be helpful to open the web console to show the error messages in these cases.
I also recommend checking Photo Booth (comes with OSX) to rule out OS camera issues whenever there's a failure.
|
|
||
Comment 24•6 years ago
|
||
(In reply to Oana Botisan from comment #21)
> Created attachment 9021166 [details]
> Screenshot 2018-10-30 at 14.42.29.png
>
> An another thing happened. When I tried to reproduce the issue again, for
> some reason the webcam system permission wasn't activated. The video was
> working, but the permission wasn't granted from the system. Please look at
> the attached image to see the issue.
If you can reproduce this, I recommend opening a second issue, so we can focus on narrowing down why the camera fails, with errors messages. I don't know if we retroactively kill permission based on changes made in System Preferences.
|
|
Reporter | |
Comment 25•6 years ago
|
||
I just managed to reproduce the issue mentioned in comment 20 without keeping the computer on sleep mode.
In the attached pic you can see what the console shows.
And photo Booth works fine. There doesn't seem to be a problem with the camera.
|
|
Assignee | |
Comment 26•6 years ago
|
||
This may be useful too.
You can get some logging about the OS permissions from Firefox using the following commands from Terminal (/Applications/Utilities/Terminal). The last command using "open" depends on where you have Firefox Beta installed. First make sure the browser is closed, then run
$ export MOZ_LOG=nsCocoaUtils:4,timestamp,sync,append
$ export MOZ_LOG_FILE=/tmp/moz_log.txt
$ open /Applications/Firefox\ Beta.app
$ tail +0f /tmp/moz_log.txt
This will log the OS permission when you attempt to use the camera in Firefox. For example, the messages below indicate video (camera) and audio (microphone) were denied (AVAuthorizationStatusDenied) by the OS.
2018-10-30 14:24:40.513682 UTC - [Parent 97484: Main Thread]:
D/nsCocoaUtils video authorization status: AVAuthorizationStatusDenied
2018-10-30 14:24:40.513723 UTC - [Parent 97484: Main Thread]:
D/nsCocoaUtils audio authorization status: AVAuthorizationStatusDenied
|
|
||
Comment 27•6 years ago
|
||
(In reply to Oana Botisan from comment #25)
> In the attached pic you can see what the console shows.
That's the Browser Console. Can you open the Web Console instead (or in addition to)? Too much noise in the other one. Thanks.
|
|
Reporter | |
Comment 28•6 years ago
|
||
Sorry for not responding sooner, but I didn't have the time to try to reproduce the issue. But I will try today and send the information you asked for as soon as I get them.
|
|
Reporter | |
Comment 29•6 years ago
|
||
I managed to reproduce the issue from comment 20 again, but the web console doesn't show any errors except:
An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can remove its sandboxing.
|
|
Reporter | |
Comment 30•6 years ago
|
||
I did the steps from comment 26, but I didn't manage to reproduce the issue while doing them. So I don't know if the results are relevant, but this is what I got:
2018-11-09 12:33:42.087495 UTC - [Parent 1262: Main Thread]: D/nsCocoaUtils video authorization status: AVAuthorizationStatusNotDetermined
2018-11-09 12:33:42.092184 UTC - [Parent 1262: Main Thread]: D/nsCocoaUtils audio authorization status: AVAuthorizationStatusNotDetermined
2018-11-09 12:33:42.092345 UTC - [Parent 1262: Main Thread]: D/nsCocoaUtils RequestCapturePermission(video)
2018-11-09 12:33:42.092375 UTC - [Parent 1262: Main Thread]: D/nsCocoaUtils RequestCapturePermission(video): 1 promise(s) unresolved
2018-11-09 12:33:44.736230 UTC - [Parent 1262: Main Thread]: D/nsCocoaUtils RequestCapturePermission(audio)
2018-11-09 12:33:44.736384 UTC - [Parent 1262: Main Thread]: D/nsCocoaUtils RequestCapturePermission(audio): 1 promise(s) unresolved
|
|
Assignee | |
Updated•6 years ago
|
|
|
Assignee | |
Updated•6 years ago
|
Summary: [Intermittent] [mac 10.14] Webcam don't work properly on some sites even if the permission is granted from the system → [Intermittent] [mac 10.14] Webcam doesn't work properly on some sites even if the permission is granted from the system
|
||
Comment 31•4 years ago
|
||
I'm unable to use Google Classroom to access the webcamera, I do not think it is the same cause as above because at every prompt I selected to allow the camera. In my OS I have /dev/video0 and /dev/video1 I'm not sure why there are two devices, in fact there is a single physical camera. I guess that it is related to the graphics card having two modes a lower-power mode and another cpu-intensive mode.
The chromium webbrowser is working out of the box and sees only a single card, Firefox v79.0 also sees a single card. The google classroom software says that the camera is starting but offers no other diagnostic information.
Other programs on the OS (cheese, v4l, document scanner) work as expected.
|
|
Assignee | |
Comment 32•4 years ago
|
||
(In reply to Anjo from comment #31)
I'm unable to use Google Classroom to access the webcamera, I do not think it is the same cause as above because at every prompt I selected to allow the camera. In my OS I have /dev/video0 and /dev/video1 I'm not sure why there are two devices, in fact there is a single physical camera. I guess that it is related to the graphics card having two modes a lower-power mode and another cpu-intensive mode.
The chromium webbrowser is working out of the box and sees only a single card, Firefox v79.0 also sees a single card. The google classroom software says that the camera is starting but offers no other diagnostic information.
Other programs on the OS (cheese, v4l, document scanner) work as expected.
Hi Anjo, this bug is an old bug for a camera issue on macOS. It sounds like you're having an issue with Firefox on a Linux distro. If so, please file a new bug using https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=WebRTC and include as much information as possible. Thanks!
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•