Closed Bug 1629984 Opened 5 years ago Closed 4 years ago

Don't enumerate suspended cameras

Categories

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

Product:
Core
Component:
WebRTC: Audio/Video
Platform:
Unspecified
macOS
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla78
Tracking Flags:
Tracking Status
firefox-esr68 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix
firefox78 --- verified

People

(Reporter: lennox, Assigned: achronop)

References

Details

Attachments

(1 file)

Bug 1629984 - Stop enumerating suspended cameras. r?padenot
47 bytes, text/x-phabricator-request
Details | Review

On macOS, cameras can be can be in a "suspended" state - notably, laptops' built-in cameras are suspended if the laptop lid is closed. See documentation at https://developer.apple.com/documentation/avfoundation/avcapturedevice/1387761-issuspended . In this state, cameras aren't able to capture media.

Right now, when Firefox enumerates devices, it nonetheless shows these suspended devices, and worse, at least on my Mac it's listed first, before my external USB camera. Thus, it's the default option in the sharing permission dialog, so the default behavior on many web applications (notably meet.jit.si) sends a black image unless I explicitly switch cameras.

Chrome does not enumerate the suspended camera. Firefox should do this as well.

This is easy to tackle and indeed chrome does not list the suspended device. I can create a patch with that fixed. Jonathan, could you please test for me if I point you to the binary? I don't have an osx currently.

Flags: needinfo?(lennox)
Priority: -- → P2

estimates: Should take about 2:46:27 (Finished around 2020-04-15 14:42)
https://treeherder.mozilla.org/#/jobs?repo=try&revision=2c950e26135a30114dc1aa042f859e0abf4491e5

I tried locally, this doesn't seem to work. This seems to be the location where we get the info, not where we enumerate.

Ops, yeah, thanks for testing, I will update it.

Yes, I'll be able to test once a binary is ready.

Flags: needinfo?(lennox)

This is the binary from the try run above: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SaqGmuDXRjWpxC4y6OlpAg/runs/0/artifacts/public/build/target.tar.bz2

It would help a lot if you can test. Thank you.

Flags: needinfo?(lennox)

Unless I'm confused, that link seems to be to a Linux build?

Flags: needinfo?(lennox)

It correctly does not report the suspended camera. However, when I un-suspend the camera (open the lid) while capturing on jitsi meet (https://meet.jit.si/SomeArbitraryConference), the tab crashes after a short period (not immediately, but less than a second).

I told Nightly to send the crash report and mentioned this bugzilla ID in the comment.

Can you find the crash report in about:crashes and copy it here?

bp-8aae75b0-7295-479c-8b87-7c8510200421 .

The crash is in CoreAudio so it might not be related; I haven't tested the same workflow with a standard Nightly. (75 doesn't crash, though.)

It would be nice to know if it happens in Nightly. We have Bug 1631814 in Nightly which is similar and we don't know how to reproduce.

The problem doesn't seem to reproduce for me with Nightly.

Does the crash reproduces every time with the binary I sent you?

Correction - I was able to get it to happen with Nightly after all. (There may be some subleties of the process that I didn't reproduce before.). I've put the steps I did on Bug 1631814.

If you can describe there the steps to reproduce it, along with the specific crash stat, it will be very helpful.

On a parallel note, can I assume that my fix on this bug increases the crash rate, assuming that it is intermitten?

No, actually I think this fix actually doesn't change the crash rate; once I do all the steps the process happens pretty regularly with regular nightly. (I think there are some subtleties about the process, probably involving microphone selection, that I wasn't doing previously.)

See Also: → 1631814

Reviewing the latest development on Bug 1631814, I think the crash is unrelated to the suspended cameras change, so I think this fix can go in safely.

Thanks for noticing, I will rebase the patch and re-send on build server in order for you to test once again if you have the time.

Looks good to me.

Suspended cameras are not able to capture data thus they are removed from the list of enumerated devices.

Assignee: nobody → achronop
Status: NEW → ASSIGNED
Pushed by achronopoulos@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f4dbf7b28512 Stop enumerating suspended cameras. r=padenot

https://hg.mozilla.org/mozilla-central/rev/f4dbf7b28512

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox78: fix-optional → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla78

I did reproduce this issue using an old Nightly build from 2020-04-14, but also I can see the FaceTime HD camera option being the first one and the default one in latest Nightly and Firefox 78.0b8.

My setup: I have a MacBook air with InsomniaX (so I can disable Lid Sleep), a external monitor connected via thunderbolt and an external camera (Microsoft LifeCam HD3000).
Steps: I close the lid on the MacBook, I open latest Nightly, visit meet.jit.si, and in the permission panel I got FaceTime HD Camera and Internal Microphone as default.

In Chrome I get the external Camera by default but the internal Microphone as well. Am I missing something? Could InsomniaX be interfering here and not make my camera be suspended?

Flags: needinfo?(achronop)

Hmm I am not familiar with InsomniaX. I don't know what they do. Does Chrome list the FaceTime HD Camera even if it is not the first in the list?

Flags: needinfo?(achronop)

(In reply to Alex Chronopoulos [:achronop] from comment #28)

Hmm I am not familiar with InsomniaX. I don't know what they do. Does Chrome list the FaceTime HD Camera even if it is not the first in the list?

It's a free software so the Mac can be used on the secondary display with the lid closed (without having the AC power connected).
Chrome does also detect the onboard webcam but it chooses the external one as default (you can't select the onboard one from the permission prompt but it can be selected from meet.jit.si menu).

Having the AC power connected (InsomniaX disabled) and the lid closed the only camera displayed in Firefox is the external one, and that's the one it uses it so this bug is fixed for the majority of the users. The same behavior if using sudo pmset disablesleep 1 to disable the lid sleep (without the AC power connected).

So bottom line: the onboard camera is still set as default only if using InsomniaX software (possible other as well) to disable the lid sleep. Do we want a new bug for that?

Flags: needinfo?(achronop)

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #29)

So bottom line: the onboard camera is still set as default only if using InsomniaX software (possible other as well) to disable the lid sleep. Do we want a new bug for that?

If it is a bug this would be definitely a new one. This patch only handles the suspended cameras and whether they are listed or not. To be more precise it filters out the suspended cameras from the enumerated devices. I am not sure what is the logic that we choose the default camera and how it interacts with InsomniaX. If you think that it is a bug, feel free to file it and we will follow up. If you are uncertain, it is better to file a bug. Thank you for taking care.

Flags: needinfo?(achronop)
No longer depends on: 1646904

(In reply to Alex Chronopoulos [:achronop] from comment #30)

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #29)

So bottom line: the onboard camera is still set as default only if using InsomniaX software (possible other as well) to disable the lid sleep. Do we want a new bug for that?

If it is a bug this would be definitely a new one. This patch only handles the suspended cameras and whether they are listed or not. To be more precise it filters out the suspended cameras from the enumerated devices. I am not sure what is the logic that we choose the default camera and how it interacts with InsomniaX. If you think that it is a bug, feel free to file it and we will follow up. If you are uncertain, it is better to file a bug. Thank you for taking care.

I think it's safe not to log a bug for the bahavior on InsomniaX since I saw that is not under development anymore since 2018 and I've also tested a few other software which can actually be found on AppStore (Insomniac, Amphetamine, AntiSleep and Don't Sleep!) and for all of those Firefox does not display the onboard webcam while the lid is closed. I'll go ahead and close this bug as verified, thanks Alex!

Status: RESOLVED → VERIFIED
status-firefox78: fixed → verified
Flags: qe-verify+
No longer regressions: 1631803
See Also: → 1631803
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: