[wayland/gnome] Opening file in *already-running app* fails to focus

ronjouch · 2024-02-12 04:00:04

Steps to reproduce

Start a “multi-document, long-running, single-instance, single-window” app. For example, gnome-text-editor
Open Nautilus, leaving the gnome-text-editor window unfocused
In Nautilus, open a .txt file with gnome-text-editor

Expected: .txt file opens in gnome-text-editor and gnome-text-editor gets focused.

Actual on a fresh install with the Feb. 2024 iso and archinstall's `Desktop / GNOME` selection: .txt file opens in gnome-text-editor and gnome-text-editor gets focused (all good!).

Actual on my main machine (installed a couple months ago): .txt file successfully opens in gnome-text-editor, but gnome-text-editor does NOT get focused.

→ This is clearly a misconfiguration of mine. Can you help me narrow down on what I messed up in my main machine? Did I uninstall or disable something critical to let xdg-activation-protocol work? Thanks.

Details

Problem is specific to already running apps! If I close gnome-text-editor and open a document with it, no problem, it gets focused. The issue happens for already-running apps whose behavior is to open the file in the existing window, e.g. in a tab.
Wayland-specific: the problem doesn’t happen in a `GNOME on Xorg` session.
Reproducible with any { caller + “multi-document, long-running / single-instance” } couple, not specific to { nautilus + gnome-text-editor }. For example, { gnome-console + Sublime Text or Firefox }. I picked the { gnome-text-editor + nautilus } couple for my example because they are “core” GNOME apps whose Wayland-well-behavedness is unambiguous
Searching the web and GNOME GitLab Issues did yield many discussions (and workarounds + extensions), but all of them are about a (resolved?) issue of not bringing to front new apps, which is not my scenario! My scenario is that already-running apps don't get focus.
Running GNOME Shell + Mutter 45.4 on Wayland 1.22.0 on an up-to-date Arch Linux.
`wayland-info | grep activation` prints: interface: 'xdg_activation_v1', version: 1, name: 28
xdg-desktop-{portal, portal-gnome, portal-gtk} installed. (Not that I know if they have anything to do with my XDG-activation-protocol problem, they just feel maybe related)
No GNOME Shell extension

V1del · 2024-02-12 16:02:07

Sounds like a broken dbus or Gtk env session. What's your output of

printenv | grep -E 'DBUS_SESSION_BUS_ADDRESS|GDK'
loginctl session-status
systemctl --user status dbus

how are you starting gnome? Via GDM?

ronjouch · 2024-02-13 02:06:44

V1del wrote:

how are you starting gnome? Via GDM?

@V1del yes, GDM.

V1del wrote:

Sounds like a broken dbus or Gtk env session. What's your output of
printenv | grep -E 'DBUS_SESSION_BUS_ADDRESS|GDK'
loginctl session-status
systemctl --user status dbus

@V1del here it is for the broken machine. I compared fresh machine vs. broken machine and couldn't find any meaningful difference. Do you see anything unhealthy here?

20:59:22 ~ printenv | grep -E 'DBUS_SESSION_BUS_ADDRESS|GDK'
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus


20:59:24 ~ loginctl session-status
16 - ronj (1000)
  Since: Sun 2024-02-11 21:42:47 EST; 23h ago
  State: active
 Leader: 466493 (gdm-session-wor)
   Seat: seat0; vc2
    TTY: tty2
 Remote: no
Service: gdm-password
   Type: wayland
  Class: user
   Idle: no
   Unit: session-16.scope
         ├─466493 "gdm-session-worker [pam/gdm-password]"
         ├─466557 /usr/lib/gdm-wayland-session /usr/bin/gnome-session
         └─466563 /usr/lib/gnome-session-binary

Feb 11 21:42:47 p systemd[1]: Started Session 16 of User ronj.
Feb 12 02:45:18 p gdm-password][560581]: gkr-pam: unlocked login keyring
Feb 12 07:01:00 p gdm-password][627838]: gkr-pam: unlocked login keyring
Feb 12 18:06:39 p gdm-password][811773]: gkr-pam: unlocked login keyring
Feb 12 20:13:48 p gdm-password][847934]: gkr-pam: unlocked login keyring


20:59:32 ~ systemctl --user status dbus
● dbus-broker.service - D-Bus User Message Bus
     Loaded: loaded (/usr/lib/systemd/user/dbus-broker.service; static)
     Active: active (running) since Sun 2024-02-11 21:42:42 EST; 23h ago
TriggeredBy: ● dbus.socket
       Docs: man:dbus-broker-launch(1)
   Main PID: 466037 (dbus-broker-lau)
      Tasks: 2 (limit: 33282)
     Memory: 3.9M (peak: 4.6M)
        CPU: 1.277s
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/dbus-broker.service
             ├─466037 /usr/bin/dbus-broker-launch --scope user
             └─466038 dbus-broker --log 4 --controller 9 --machine-id MACHINE_UUID_HERE --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000

Feb 11 21:42:42 p dbus-broker-launch[466037]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +31: Eavesdropping is deprecated and ignored
Feb 11 21:42:42 p dbus-broker-launch[466037]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored
Feb 11 21:42:42 p systemd[4712]: Started D-Bus User Message Bus.
Feb 11 21:42:42 p dbus-broker-launch[466037]: Ready
Feb 12 18:07:11 p dbus-broker-launch[466037]: Noticed file-system modification, trigger reload.
Feb 12 18:07:11 p dbus-broker-launch[466037]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +31: Eavesdropping is deprecated and ignored
Feb 12 18:07:11 p dbus-broker-launch[466037]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored
Feb 12 18:07:11 p dbus-broker-launch[466037]: Noticed file-system modification, trigger reload.
Feb 12 18:07:11 p dbus-broker-launch[466037]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +31: Eavesdropping is deprecated and ignored
Feb 12 18:07:11 p dbus-broker-launch[466037]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored

Last edited by ronjouch (2024-02-13 02:07:09)

tekstryder · 2024-02-14 20:00:00

ronjouch wrote:

[*]Problem is specific to already running apps! If I close gnome-text-editor and open a document with it, no problem, it gets focused. The issue happens for already-running apps whose behavior is to open the file in the existing window, e.g. in a tab.[/*]

Do you get any "app is ready" notification when this occurs? If so, that's mutter's intentional focus-stealing prevention in action.

And would be:
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/358

There are extensions to mitigate this behavior.

ronjouch · 2024-02-15 02:41:05

tekstryder wrote:

Do you get any "app is ready" notification when this occurs? If so, that's mutter's intentional focus-stealing prevention in action.
There are extensions to mitigate this behavior: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/358

@tekstryder this is it (sadly with caveats, see below), thank you! And welp, in my research I had stumbled upon this thing, but didn't associate to my issue! As mentioned in my OP:

ronjouch wrote:

Searching the web and GNOME GitLab Issues did yield many discussions (and workarounds + extensions), [...]

So, what's the result after installing the extension (and logging out/in)? It halfway works. In particular, it manages to let "focus stealing" happen when gnome-text-editor is *behind* Nautilus, but if the windows don't overlap (gnome-text-editor strictly next to Nautilus), then Nautilus still doesn't get focus, breaking immediate keyboard navigation :-/ .

Also, any idea why the extension is needed for focus stealing to semi-work on my main machine, while it's unnecessary on the fresh machine? I just tested the fresh machine (imaged a day ago with a brand new Arch iso Feb. 2024), and

Focus stealing when gnome-text-editor is invoked as it is behind Nautilus: works with no extension
Focus stealing when gnome-text-editor is invoked while *next to* Nautilus (no overlap): also works with no extension

<not even a rant, more like sad resignation>This shell/mutter bug you linked to is so saaaaaaaaaaad. So much discussion to try to improve an (admittedly less than ideal) situation, yet end up throwing in the towel and worsening the experience of a lot of users, as demonstrated by the abundance of upvotes, lingering corner cases and extensions, which themselves only half-work :-//// . Blergh, that's one too many small-but-piling-up GNOME/Wayland annoyances for me; back to Xorg while I can, and will give Plasma 6 a try when it's out.</not even a rant, more like sad resignation>

Last edited by ronjouch (2024-02-15 03:42:27)

tekstryder · 2024-02-15 13:26:16

ronjouch wrote:

Also, any idea why the extension is needed for focus stealing to semi-work on my main machine, while it's unnecessary on the fresh machine? I just tested the fresh machine (imaged a day ago with a brand new Arch iso Feb. 2024), and
Focus stealing when gnome-text-editor is invoked as it is behind Nautilus: works with no extension
Focus stealing when gnome-text-editor is invoked while *next to* Nautilus (no overlap): also works with no extension

No idea. The distinction here is whether the text editor is already running when you "invoked". If it was not running, the default mutter behavior would open and focus the text editor. Subsequent text files opened from nautilus would then _not_ focus the already-running editor by default, hence the extension's existence.

Are you using this extension? This one is working for me on gnome 45.4 and 46.beta.

ronjouch wrote:

<not even a rant, more like sad resignation>

I've not chimed in on the bug report because I believe the rationale and impetus for the implementation of focus-stealing prevention (by certain apps I do not use) is sound.

Also, the extension is a simple one-liner that changes the default behavior to what I prefer, and also prevents the annoying "app is ready" notification.

ronjouch · 2024-02-16 19:18:56

tekstryder wrote:

ronjouch wrote:
Also, any idea why the extension is needed for focus stealing to semi-work on my main machine, while it's unnecessary on the fresh machine?
No idea. The distinction here is whether the text editor is already running when you "invoked". If it was not running, the default mutter behavior would open and focus the text editor. Subsequent text files opened from nautilus would then _not_ focus the already-running editor by default, hence the extension's existence.

Yup, I get it now. Thx! But in my testing, 1. there's absolutely a shenanigan depending on windows overlapping or not, and 2. I'm bewildered by the extension being necessary on my main machine, but not on the freshly-imaged test machine.

tekstryder wrote:

Are you using this extension?

Yup!

tekstryder wrote:

ronjouch wrote:
<not even a rant, more like sad resignation>
I've not chimed in on the bug report because I believe the rationale and impetus for the implementation of focus-stealing prevention (by certain apps I do not use) is sound.

Sure. I'll find some motivation to fully read it, and will add to it if I believe my case adds something. Thanks again for the halp

With this, not marking as [resolved], since I still don't understand points 1. & 2. listed above.

Last edited by ronjouch (2024-02-17 18:31:52)

Arch Linux

#1 2024-02-12 04:00:04