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

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.

(see https://gitlab.gnome.org/GNOME/snapshot/-/issues/136#note_2056326 for the helpful hint)

(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.

yeah, to confirm, updating the portal didn't help me either.

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.

Fabio has pointed us to this racy code which he suspects is the problem here:

impl WidgetImpl for Window {
        fn map(&self) {
            self.parent_map();
            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.
                glib::timeout_future(std::time::Duration::from_millis(50)).await;
                camera.start().await;
            }));
        }
    }

more context: this is from snapshot-46.1/src/widgets/window.rs, lines 179-191

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.

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.

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.

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.

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.

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.

> 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".

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.

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.

FEDORA-2024-b5511d9802 (snapshot-46.1-3.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-b5511d9802

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.

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.

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

snapshot-46.1-3.fc40

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.