I had similar symptoms with Ubuntu 26.04 on Lenovo Carbon X1. Finally
managed to make it work with Claude, don't think I would've had enough
patience to see it through myself.

I saved the findings here for future reference:
https://gist.github.com/AlexeySalmin/d5f74fa9cb2fa02c1bb562eb912cae2c

For your case it seems almost OK already, most of the steps already
done, what remains is the busctl command.

The below is the summary generated by Claude.

Confirming this on different hardware, which I think rules out anything
sensor- or platform-specific:

  ThinkPad X1 Carbon Gen 13 (Lunar Lake), ov08x40 sensor / Intel IPU7
  Ubuntu 26.04, kernel 7.0.0-27-generic
  xdg-desktop-portal 1.21.1+ds-1ubuntu3
  xdg-desktop-portal-gnome 50.0
  GNOME / Wayland, Google Chrome 150.0.7871.124

Same symptom, same log pair as the original report. The camera itself is
fully functional underneath: libcamera's "cam -l" lists it, PipeWire exposes
an "ov08x40 [libcamera]" node, and the portal answers IsCameraPresent = true.
Only the permission dialog is broken.

With chrome://flags/#enable-webrtc-pipewire-camera enabled, Chrome hangs at
launch, and journalctl --user -b shows:

  xdg-desktop-portal-gnome[...]: Failed to associate portal window with parent 
window
  /usr/libexec/xdg-desktop-portal[...]: A backend call failed:
    GDBus.Error:org.freedesktop.DBus.Error.AccessDenied:
    Only the focused app is allowed to show a system access dialog


A diagnostic that may help narrow this down
-------------------------------------------

GNOME Snapshot works fine on the same system throughout. The difference is
not that Snapshot is special -- it is that it already holds a stored
permission, so AccessCamera returns immediately and never needs a dialog:

  $ busctl --user call org.freedesktop.impl.portal.PermissionStore \
      /org/freedesktop/impl/portal/PermissionStore \
      org.freedesktop.impl.portal.PermissionStore Lookup ss "devices" "camera"
  a{sas}v 1 "org.gnome.Snapshot" 1 "yes" y 0

Chrome has no entry, so the request has to prompt. Chrome asks for camera
access at startup, before its window is focused, which is exactly the case
GNOME Shell refuses. The call is then left pending and Chrome waits forever.

So the trigger looks like: no stored permission + a request made while the
app is not focused.


Workaround
----------

Pre-seed the permission, so the broken dialog is never reached:

  busctl --user call org.freedesktop.impl.portal.PermissionStore \
    /org/freedesktop/impl/portal/PermissionStore \
    org.freedesktop.impl.portal.PermissionStore \
    SetPermission sbssas "devices" true "camera" "com.google.Chrome" 1 "yes"

Then fully quit and relaunch Chrome. This resolved it here: no hang, and the
camera is available in Chrome.

To revert:

  busctl --user call org.freedesktop.impl.portal.PermissionStore \
    /org/freedesktop/impl/portal/PermissionStore \
    org.freedesktop.impl.portal.PermissionStore \
    DeletePermission sss "devices" "camera" "com.google.Chrome"

The app id has to match what the portal derives for the application, which
comes from its systemd scope. Rather than guessing it:

  $ cat /proc/$(pgrep -f /opt/google/chrome/chrome | head -1)/cgroup
  
0::/user.slice/user-1000.slice/[email protected]/app.slice/app-com.google.Chrome-29417.scope
                                                                 
^^^^^^^^^^^^^^^^^^

hence "com.google.Chrome". It will differ for other browsers and for
snap/flatpak packagings, so it is worth checking rather than assuming. I have
only verified the Chrome .deb; I have not tested the Firefox equivalent.


Caveats
-------

This is a workaround, not a fix, and it is not a good general recommendation:
it grants camera access unconditionally and bypasses the consent step
entirely. It is only reasonable on a machine where you would have clicked
"allow" anyway.

It also does nothing for the underlying problem -- any app with no stored
permission that requests camera access before its window is focused will
still hang. If it helps in triage: the indefinite hang seems worse than the
denial itself. A backend call that cannot show its dialog returning an error,
rather than being left pending, would at least let the application fail
visibly instead of freezing.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2158647

Title:
  xdg-desktop-portal 1.21.1: Camera access denied in Chrome/Firefox on
  Wayland - "Only the focused app is allowed"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/2158647/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to