1920385 - [Wayland][Strict focus] Support the xdg-activation wayland protocol on Linux

Status: RESOLVED FIXED

(Core :: Widget: Gtk, enhancement, P3)

Description

[evanmohr22]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0

Steps to reproduce:

1. Set Gnome to restrict focus stealing protection using "gsettings set org.gnome.desktop.wm.preferences focus-new-windows 'strict'"
2. Open a Firefox window
3. In the hamburger menu / 3 dash menu, click "New Window"

Actual results:

The original window remains focused.

Expected results:

The new window should become focused.

More details:
When Gnome is set to restrict focus stealing prevention, protections are put in place so that windows don't randomly steal focus from windows the user is actually using. To properly hand over focus to a new window, the xdg-activiation wayland protocol should be implemented.

Currently, this is not an issue for Firefox since Gnome currently defaults to "smart" focus stealing protection. This mode lets windows become focused even without implementing the xdg-activation protocol. However, Gnome may make strict focus stealing protection default in the future, so Firefox should be prepared for that eventuality.

Links to learn more:
Protocol information: https://wayland.app/protocols/xdg-activation-v1
Gnome blog post about focus stealing protection and xdg-activiation: https://blogs.gnome.org/shell-dev/2024/09/20/understanding-gnome-shells-focus-stealing-prevention/

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:enndeakin, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[:gerard-majax]

Jan, since you were working on other XDG protocol maybe you are interested in this one?

Comment 4

[Jan Grulich]

(In reply to :gerard-majax from comment #3)

Jan, since you were working on other XDG protocol maybe you are interested in this one?

This is a wayland procotol. I think Martin Stránský is the right person for this to implement.

Comment 5

[Jan Grulich]

Actually, isn't this already implemented https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#3044?

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Yes, it's already implemented. Maybe Firefox fails to call it correctly, we use nsWindow::SetFocus() and we need to have already focused nsWindow to transfer focus from.

If anybody is interested in debugging it I'd set breakpoint to nsWindow::SetFocus() and check how it's processed.

Comment 7

[Rob Wu [:robwu]]

FYI, I see the following comment in nsWindow::SetUrgencyHint at https://searchfox.org/mozilla-central/rev/04a2c5317c0af560ed1689304498416c9c6c485a/widget/gtk/nsWindow.cpp#7019

// TODO: Use xdg-activation on Wayland?

Comment 8

[Martin Stránský [:stransky] (ni? me)]

(In reply to Rob Wu [:robwu] from comment #7)

FYI, I see the following comment in nsWindow::SetUrgencyHint at https://searchfox.org/mozilla-central/rev/04a2c5317c0af560ed1689304498416c9c6c485a/widget/gtk/nsWindow.cpp#7019

// TODO: Use xdg-activation on Wayland?

That's not related here.

Comment 9

[ales.astone]

Attachment: Bug 1920385 - Send xdg-activation token over xdg-desktop-portal r=emilio,stransky

GLib routes open-URI requests through the xdg-desktop-portal when the
application is running in a sandboxed environment. It retrieves the
activation token by calling GAppLaunchContext::get_startup_notify_id.

GAppLaunchContext is a pure abstract class, which does not define the
get_startup_notify_id method. Instead, normally the GdkAppLaunchContext
is used, which gets the xdg-activation token from the Wayland server on-demand.

Because Firefox retrieves the xdg-activation token manually instead, we
should subclass GAppLaunchContext to define our get_startup_notify_id method,
which simply return the token we had previously obtained.

This allows focusing the new window when opening a URI externally from a
sandboxed Firefox or Thunderbird.

Comment 10

[Phabricator Automation]

Comment on attachment 9491051 [details]
Bug 1920385 - Send xdg-activation token over xdg-desktop-portal r=emilio,stransky

Revision D251404 was moved to bug 1968910. Setting attachment 9491051 [details] to obsolete.

Comment 11

[ales.astone]

Attachment: Bug 1920385 - Request transfering focus to a new firefox window on Wayland r=emilio,stransky

When opening a new window we might find an xdg-activation token passed in
from the external environment, or we might be opening a new window ourselves.
In the latter case, we need to request to transfer the focus from our current
focused window to the newly created window.

Comment 12

[ales.astone]

This requires a fix in both firefox and mutter: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4462

Comment 13

[Martin Stránský [:stransky] (ni? me)]

To be clear, I'm not saying it's wrong or bad. I think we need to compare the behavior with X11 and better understand the intent here.

I wonder what issue do you want to address here - I haven't seen any reports about missing focus of new windows or so. Do you address any particular issue you hit?

You say:

Set Gnome to restrict focus stealing protection using "gsettings set org.gnome.desktop.wm.preferences focus-new-windows 'strict'"

I don't quite understand why do you tighten the rules and than want to implement a fix for it? Is the 'strict' policy used anywhere? Or why do you set it?

Thanks.

Comment 14

[Martin Stránský [:stransky] (ni? me)]

btw. it's not important how do you want to transfer the focus, if by xdg-token, automatically or by SetFocus() call... I rather wonder why we need such explicit actions here?

Comment 15

[Martin Stránský [:stransky] (ni? me)]

Ahh, I think I understand now, looking at https://blogs.gnome.org/shell-dev/2024/09/20/understanding-gnome-shells-focus-stealing-prevention/
IIUC this is an effort to implement focus stealing feature correctly and support strict focus transfer rules by various applications, right?

Comment 16

[ales.astone]

I don't quite understand why do you tighten the rules and than want to implement a fix for it? Is the 'strict' policy used anywhere? Or why do you set it?

Because we want Firefox to be ready for when "strict" becomes the default (beware: it's probably not anytime soon, but don't take my word for it).
"strict" doesn't mean "don't focus new windows", it means "don't focus new windows unless they provide proof of user action" and we would like to comply we that.

Comment 17

[Martin Stránský [:stransky] (ni? me)]

Okay, makes sense. Will read the blog tomorrow and look at the patch again.
Thanks.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/d64a00cd0822
https://hg.mozilla.org/integration/autoland/rev/5d57d47f8501
Request transfering focus to a new firefox window on Wayland r=emilio,stransky

Comment 19

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/5d57d47f8501