Bug 2274061 - snapshot often shows "No Camera Found" when launched from the overview, but finds camera when launched from a console
Summary: snapshot often shows "No Camera Found" when launched from the overview, but f...
Alias: None
Product: Fedora
Classification: Fedora
Component: snapshot
Version: 40
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: GNOME SIG Unassigned
QA Contact:
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F40FinalBlocker F40FinalFreezeException
TreeView+ depends on / blocked
Reported: 2024-04-08 22:18 UTC by Adam Williamson
Modified: 2024-04-11 18:42 UTC (History)
8 users (show)

Fixed In Version: snapshot-46.1-3.fc40
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2024-04-11 18:42:06 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME snapshot issues 156 0 None opened Starting Snapshot for the first time causes camera permission to be permanently denied, without user input 2024-04-09 23:51:22 UTC

Description Adam Williamson 2024-04-08 22:18:54 UTC
Exactly as described in summary. This reproduces just about every time for me, and multiple others have reported the same. When launched from the overview, Snapshot just shows "No Camera Found". When launched from gnome-terminal, it finds the camera (for me it then crashes - https://bugzilla.redhat.com/show_bug.cgi?id=2273497 - but for folks with different cameras it works).

Various upstream issues make a comment about this perhaps involving some kind of race between portal permissions and the app starting up. I'm not sure exactly which of the many "No Camera Found" issues at https://gitlab.gnome.org/GNOME/snapshot/-/issues this should be linked to.

Proposing as a Final blocker as a violation of "Additionally, for Fedora Workstation on the x86_64 architecture, all applications installed by default which can be launched from the Activities menu must [start successfully and withstand a basic functionality test]" - https://fedoraproject.org/wiki/Fedora_40_Final_Release_Criteria#Default_application_functionality

Comment 1 Michael Catanzaro 2024-04-09 12:51:44 UTC
This one might possibly be fixed by xdg-desktop-portal 1.18.3. Do you have 1.18.3 installed? https://bodhi.fedoraproject.org/updates/FEDORA-2024-08fe18512d

Comment 2 Fabio Valentini 2024-04-09 13:09:15 UTC
I don't think the xdg-desktop-portal update fixes this issue. I tested this again on both of my systems, and on both of them I still get "No camera found" when opening snapshot from the desktop launcher.

When launched from the terminal, snapshot crashes on both systems (Logitech C920 Pro webcam on one system, integrated webcam from Dell XPS 13 on my other system), but the "something on this system is using the webcam" indicator in GNOME Shell appears for a few seconds - which does *not* happen when launching from the desktop overview (where I get "No Camera found" immediately on launch).

Note that one of the upstream issues for "No Camera found" actually contained something helpful:

Going to GNOME Settings -> Privacy and Security -> Cameras, I see that "Camera" (i.e. Snapshot) is not allowed access under "Permitted Apps".
If I toggle this setting manually, launching Snapshot from the desktop launcher starts to work (even though it's still very crashy).

This definitely points toward the Camera portal as being the culprit.

Comment 3 Fabio Valentini 2024-04-09 13:10:11 UTC
(see https://gitlab.gnome.org/GNOME/snapshot/-/issues/136#note_2056326 for the helpful hint)

Comment 4 Brian Morrison 2024-04-09 15:11:47 UTC
(In reply to Fabio Valentini from comment #2)

> Going to GNOME Settings -> Privacy and Security -> Cameras, I see that
> "Camera" (i.e. Snapshot) is not allowed access under "Permitted Apps".
> If I toggle this setting manually, launching Snapshot from the desktop
> launcher starts to work (even though it's still very crashy).

snapshot now works for me from overview after changing the permission in the GNOME settings, it also allows a photo to be taken and doesn't crash in this case.

Whether it's entirely stable I don't know.

Comment 5 Adam Williamson 2024-04-09 15:32:04 UTC
yeah, to confirm, updating the portal didn't help me either.

Comment 6 Fabio Valentini 2024-04-09 15:44:57 UTC
As far as I can tell by looking at the code of snapshot, and putting things together I have learned about how snapshot + the camera portal works, this issue is caused by the following race condition upon first launch:

1. snapshot initializes its state and builds the UI
2. snapshot window is "presented" on screen (or whatever the correct term is in GTK-land)
3. step 1. seems to include asynchronously asking the camera portal for permission over DBus

Whenever asking for permission in step 3. happens before rendering the window in step 2., the portal doesn't even present a dialog to grant camera permission because applications without windows are apparently denied camera permission by default.

Looking at the UI code in snapshot, the "No Camera found" UI is reused for "permission denied", so that makes sense too.

And the "Camera access denied" permission for the portal seems to be stored somewhere, so the dialog is never shown again. The only way to grant the permission if the race condition is hit on first launch seems to be to grant the permission in GNOME Settings' "Privacy" settings explicitly.

As far as I can tell, adding something like a "barrier" to ensure "window is rendered on-screen" always happens before "portal is asked for camera access" should fix this issue, but I don't know the snapshot code base well enough to be able to quickly whip up a patch to test this hypothesis.

Comment 7 Michael Catanzaro 2024-04-09 17:19:19 UTC
Fabio has pointed us to this racy code which he suspects is the problem here:

impl WidgetImpl for Window {
        fn map(&self) {
            let camera = self.camera.get();
            glib::spawn_future_local(glib::clone!(@weak camera => async move {
                // HACK we add a small timeout to give the shell time to get the
                // windows focus, otherwise the Shell won't ask for camera
                // permission.

Comment 8 Fabio Valentini 2024-04-09 17:21:29 UTC
more context: this is from snapshot-46.1/src/widgets/window.rs, lines 179-191

Comment 9 Adam Williamson 2024-04-09 17:48:49 UTC
OK, so some more background here.

That 50ms wait hack was only added recently: https://gitlab.gnome.org/GNOME/snapshot/-/merge_requests/201 . It was merged upstream on Feb 17 and reached stable downstream on Feb 22. It was actually added in response to a bug I filed - https://gitlab.gnome.org/GNOME/snapshot/-/issues/122 - based on openQA testing. openQA was frequently hitting this very problem - about half the time, when it ran Snapshot, it didn't get the permission dialog like it should, it just got a window with an eternal spinner.

Since that hack was added and landed downstream, openQA has not hit that problem one time. I also just tried myself a few times in today's F40 nightly live in a VM, rebooting between tries, and each time I correctly got the permission prompt.

So...I think we can possibly say that for *fresh installs*, this is probably sufficiently resolved already.

As Fabio wrote, it seems like if you hit this bug once, the rejected permission is 'baked in' until you go and change it in the control center. Which sucks, obviously, and we should document that for folks who tried running snapshot before the 50ms wait was added. But I think perhaps for fresh installs this should no longer be very likely to happen, and maybe that affects the blocker vote.

Comment 10 Adam Williamson 2024-04-09 17:58:49 UTC
btw, it would be good if folks can test booting a recent live image and trying to launch Snapshot a few times. it's possible that 50ms wait isn't enough in all cases and it'll still be possible to hit the bug. if we can't manage to hit the bug, or only very rarely, that's a good sign.

Comment 11 Michael Catanzaro 2024-04-09 18:34:17 UTC
I can't reproduce this myself. It would be helpful if one of you could report a new bug report on the upstream issue tracker. It will probably turn out to be a duplicate of one of the existing bugs, but it's hard to know for sure, so a new one will be best for now.

Comment 12 Michael Catanzaro 2024-04-09 20:31:59 UTC
I am able to reproduce this 100% of the time now after running 'flatpak permission-reset org.gnome.Snapshot' to remove the camera permission. The first time I ran Snapshot, its permission request was automatically and permanently denied. I believe this bug is either https://gitlab.gnome.org/GNOME/snapshot/-/issues/109 or https://gitlab.gnome.org/GNOME/snapshot/-/issues/134 or they are duplicates; I'll link this downstream issue to both of them. This only happens when running Snapshot from the overview and not from a terminal.

If I run Snapshot from a terminal, then it hangs instead, which I've reported as https://gitlab.gnome.org/GNOME/snapshot/-/issues/153. This seems like a separate bug that isn't blocker-worthy because users don't generally run apps from the terminal.

Comment 13 Michael Catanzaro 2024-04-09 20:43:53 UTC
Adam has reported https://gitlab.gnome.org/GNOME/snapshot/-/issues/154 for the inconsistency between opening the app from the overview vs. from the terminal.

And I've reported https://gitlab.gnome.org/GNOME/snapshot/-/issues/153 for a hang, but that seems like a separate bug.

Comment 14 Adam Williamson 2024-04-09 21:04:57 UTC
So, I'm not sure Michael is exactly reproducing the initial bug here.

I've been testing for the last few minutes by booting today's F40 Workstation live nightly (from a USB stick) on my test box and running snapshot. So far, every time I've done that, I've seen the permission request dialog and it's behaved correctly.

However, if *after* doing that and then re-launching snapshot to confirm the permission setting 'stuck', I then run `flatpak permission-reset org.gnome.Snapshot` and run Snapshot again, it shows a spinner for several seconds then shows No Camera Found. I've reproduced that twice now. So I'm not sure `flatpak permission-reset org.gnome.Snapshot` is actually restoring a completely clean state. Rather, perhaps that is yet another *different* bug.

Comment 15 Michael Catanzaro 2024-04-09 21:08:15 UTC
> I've been testing for the last few minutes by booting today's F40 Workstation live nightly (from a USB stick) on my test box and running snapshot. So far, every time I've done that, I've seen the permission request dialog and it's behaved correctly.

I tested with a brand new test user account, and there I see the permission request dialog, ***but only if I run Snapshot from a terminal.*** If I run it from the overview, then it fails as described in comment #12.

Even when I run from the terminal and grant the camera access permission, it still fails and says "No Camera Found".

Comment 16 Adam Williamson 2024-04-09 21:19:11 UTC
I've now tested 10+ times on my test bare metal box, fresh live boot every time, and haven't yet had the permission dialog not appear one time. I've found plenty of *other* weirdness, but that has not gone wrong yet.

Comment 17 Michael Catanzaro 2024-04-09 23:58:57 UTC
I think there's multiple upstream bugs involved here, but https://gitlab.gnome.org/GNOME/snapshot/-/issues/156 which I've just reported is the closest match and that's what we should track in this particular downstream bug.

Comment 18 Fedora Update System 2024-04-10 00:07:19 UTC
FEDORA-2024-b5511d9802 (snapshot-46.1-3.fc40) has been submitted as an update to Fedora 40.

Comment 19 Adam Williamson 2024-04-10 00:21:17 UTC
We have +2 for FE and +1 for blocker in https://pagure.io/fedora-qa/blocker-review/issue/1581 , counting that as +3 FE and marking accepted FE. This is to get the build with portal/permission stuff disabled into the RC.

Comment 20 Fedora Update System 2024-04-10 01:59:42 UTC
FEDORA-2024-b5511d9802 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-b5511d9802`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-b5511d9802

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 21 Geraldo Simião 2024-04-10 03:52:03 UTC
Ok, no more "Turn On Camera?" permission dialog here, on a fresh installed and updated F40 Workstation. 
Camera working fine. => ID 1bcf:2c18 Sunplus Innovation Technology Inc. HD WebCam


Comment 22 Fedora Update System 2024-04-11 18:42:06 UTC
FEDORA-2024-b5511d9802 (snapshot-46.1-3.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.