Open Bug 1873981 Opened 1 year ago Updated 1 month ago

[Wayland] Firefox doesn't raise to the top when a link is clicked in other app or document

Categories

(Core :: Widget: Gtk, defect, P2)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 121
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: michal.dybczak, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

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

Steps to reproduce:

Use latest Plasma, preferably on Arch, Manjaro or other Arch based distro. I didn't check it on the DEs, so I'm not sure if the issue is DE related. I also don't know if this is distro related.

Open Firefox (as a default browser) and either minimize it or put it behind another app (so it's not on the top layer).

Then click a link in other app (mailing app like Thunderbird) or document (Libre Office Writer, PDFs, etc.).

Actual results:

Instead of raising the Firefox window to the top after clicking a link, the window becomes alerted, blinking red but stays in the background.

Expected results:

After clicking a link in non-Firefox app or document, Firefox window should be raised to the top.

I checked Wayland and X11 and the issue happens in both session.
The problem exists on all users, even default ones.
The same happens on a completely different computer with basically vanilla settings, but the same distro (Manjaro) and DE (Plasma), proving that this is a global Firefox issue.

I also checked browser.tabs.loadDivertedInBackground and browser.tabs.loadInBackground and those are already set to false and I do have plasma-browser-integration which is enabled in Firefox.

Granted, it has to be yet ruled out if this happens in other DEs or distros.

That behavior is problematic, because when working frequently with external links (like I do for work) to open various, specific sites or link to documents, it forces the user to do a manual click action to raise the Firefox window. If this needs to be done many times a day, it quickly becomes tiring and unnecessary. Especially, that when switched to other default browsers, they are raised to the top correctly. Besides, not long ago, Firefox also worked correctly in that instance, and now it becomes unsuited for work.

I believe the problem started with the Firefox 121 update, because I don't recall this happening prior to it.

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

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Component: Widget: Gtk → General

I couldn't reproduce this on Win11. According to the comment 0, it looks to me that Widget:Gtk is the right component to start with.

Dear reporter,
If you could help us run https://mozilla.github.io/mozregression/install.html to get the regression window, that could be very helpful.

Component: General → Widget: Gtk
OS: Unspecified → Linux

I checked:

  • Windows10: no issue
  • Linux Mint X11 session: no issue
  • Manjaro KDE live X11 session: no issue
  • Manjaro KDE live Wayland session: issue confirmed

If you look on the topic where I first asked about it on Manjaro forum:

https://forum.manjaro.org/t/firefox-doesnt-raise-window-after-clicking-a-link/154842/14

all users who confirm this issue, confirm this in Wayland.

Although it seems that the problem for me extends to X11, from this it looks like Wayland is the problem, or more accurately, the Firefox Wayland implementation is here at fault. It confirms my observation, that prior 121, there was no issue, because Firefox was running as XWayland app, not native Wayland like it is now.

On the 121 release notes:
https://www.mozilla.org/en-US/firefox/121.0/releasenotes/
you can read:

"On Linux, Firefox now defaults to the Wayland compositor when available instead of XWayland. This brings support for touchpad & touchscreen gestures, swipe-to-nav, per-monitor DPI settings, better graphics performance, and more."

Please, contact the developers who are responsible for this part of the development. They will know and understand what is happening here.

Also, I installed Mozregression, but I'm not sure what to do now. I see 3 options:

  • run a new bisection (scissor icon),
  • run a single build
  • stop bisection or single build

Given the fact that the Firefox behavior may be tied to Wayland protocols, there will be no apparent regression, as this issue is the bug or limitation of Wayland protocol in Firefox.

Other browsers like Chromium don't have this issue, but those run as XWayland at the moment, so this is possible, that the problem is caused upstream with Wayland itself, or Kwin Wayaland compositor. It is important to identify which one is it, to report it to proper place.
Thank you

I installed Manjaro Gnome in virtualbox.
In X11 - no issue
In Wayland - issue exists, so basically instead of raising a Firefox window to the foreground after clicking a link, I get a pop-up "Your Firefox window is ready", which is a Gnome version of showing that the app is demanding attention.

So basically, this confirms that the core problem comes with Wayland session, no matter of DE.

The question is: is this a Wayland upstream problem, or Firefox implementation of Wayland? Again, the devs who were working on making Firefox Wayland native will know this, so I will appreciate forwarding this report to them.
Thank you.

Hardware: Unspecified → x86_64
Summary: Firefox doesn't raise to the top when a link is clicked in other app or document → [Wayland] Firefox doesn't raise to the top when a link is clicked in other app or document

It's a general issue with all wayland application. You can reproduce it with gnome-terminal for instance.

Blocks: wayland
Priority: -- → P3

btw. There's an extension available which removes the notification and raise window automatically:
https://extensions.gnome.org/extension/6385/steal-my-focus-window/

Flags: needinfo?(stransky)
See Also: → https://extensions.gnome.org/extension/6385/steal-my-focus-window/

Didn't took time to report this yet, but I've been seeing this on Wayland for some time now. This might be a normal behavior of Wayland, or maybe just nothing can be done about this, but I think it should behave uniformly across both x11 and Wayland. The best would be to have it configurable for the best of both worlds and satisfy every user.

Note that when the system is loaded/slowed down (which might happen with some DEs), Gnome produce a notification saying Firefox is ready, but that notification can be generic or even have the text of the current tab on Firefox rather than the new one, because Firefox didn't have time to open the new one.

If this is a Wayland behavior or more accurately, Wayland limitation, then this should be known, so we could influence Wayland developers to make it behaved like on X11 or Windows. This is the kind of behavior which we expect and which creates an easy workflow. I literally click 20-40 links a day during a work (various mails and databases with links to important documents), and now I have to click the Firefox icon as well, to get them opened. Sometimes, I don't know if I correctly clicked the link, so I click it again. This causes me to open the same links multiple times by accident. This is annoying and unnecessary.

There are desktop standards that arose during a few decades of using it, so there is a strong reason why this behavior is the same on X11 and on Windows. I don't know how it works on Mac, but I suspect it's the same. Wayland needs to be on-pair to long-established solutions. If not, Wayland will always be an inferior experience for no real reason. Because this was a standard for so long ago, and there is no practical reason to change it, I doubt that there is a need to customize that experience. It could be done, but this is not necessary. There was no such option on X11 and there is no such option on Windows, and no one is crying about it, because this is a good default.

At this point, I want to know, what is the real cause of this. Is it on Wayland or Firefox side?

I've been hearing that there is a way to make Chromium Wayland native with a flag. I'll look for it and if it works, I make it a default browser to test if it has the issue or not. This should tell us clearly on which side the problem is.

OK, I was able to open native Chrome or Chromium windows with those commands:

$ google-chrome-stable --enable-features=UseOzonePlatform --ozone-platform=wayland
or
$ chromium --enable-features=UseOzonePlatform --ozone-platform=wayland

After that, Chromium or Chrome behaved exactly as Firefox, namely, all links clicked from external apps (Thunderbird, Libre Office Writer) didn't raise to the foreground, only were alerted (blinked red, in my case).

This answers the question and makes clear that this is a Wayland limitation. Now, I need to check, where to report Wayland issues.

Note, that some people claim to not have this issue, but I'm not convicted that really opened Firefox as Wayland window. I'm checking if the window is a Wayland one from KDE Debug Window Wayland console, which clearly shows which window is Wayland and which XWayland one. If some wants to use it, here is the command:

$ qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole

Various settings, flags, environment variables may cause Firefox to open as XWayaland for some, and they don't bother checking. I have done some many tests in so many environments and various windows settings, and it was 100% replicable that on X11 all worked as before, on Wayland, links were not raising the browser window.

What status of the report should I set, if it was established that this is not a Firefox fault? UPSTREAM? Is there such status?

(In reply to michal.dybczak@gmail.com from comment #10)

OK, I was able to open native Chrome or Chromium windows with those commands:

$ google-chrome-stable --enable-features=UseOzonePlatform --ozone-platform=wayland
or
$ chromium --enable-features=UseOzonePlatform --ozone-platform=wayland

After that, Chromium or Chrome behaved exactly as Firefox, namely, all links clicked from external apps (Thunderbird, Libre Office Writer) didn't raise to the foreground, only were alerted (blinked red, in my case).

This answers the question and makes clear that this is a Wayland limitation. Now, I need to check, where to report Wayland issues.

Note, that some people claim to not have this issue, but I'm not convicted that really opened Firefox as Wayland window. I'm checking if the window is a Wayland one from KDE Debug Window Wayland console, which clearly shows which window is Wayland and which XWayland one. If some wants to use it, here is the command:

$ qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole

Various settings, flags, environment variables may cause Firefox to open as XWayaland for some, and they don't bother checking. I have done some many tests in so many environments and various windows settings, and it was 100% replicable that on X11 all worked as before, on Wayland, links were not raising the browser window.

What status of the report should I set, if it was established that this is not a Firefox fault? UPSTREAM? Is there such status?

Please leave it open, we may track it with reference to upstream issue - https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/358
There's also workaround for it - https://extensions.gnome.org/extension/6385/steal-my-focus-window/

See Also: → 1896457

There is new information about this issue in my original Manjaro forum topic. User @axum provided very important info, that shows, that there is a solution and Firefox must take one step to solve it. Thunderbird already implemented it, and it correctly raises Firefox windows when a link is clicked in an email.

Here is the copy of his post:

"[...] I want to add some important information.

By default, wayland does not allow windows to just put themselves into arbitrary z positions.

However, to facilitate exactly this scenario of having web links or other items pop up the appropriate window, a protocol was added to Wayland to handle this.

This protocol is the XDG activation token: wayland.app/protocols/xdg-activation-v1

Fortunately, both Firefox and Chromium bases browsers already support this protocol as of the beginning of this year.

“But then why doesnt the browser raise when links are clicked?”

Therein lies the gotcha.

Each application must explicitly build in support for this new wayland protocol and pass it to the compositor to handle. Some programs, like Thunderbird, KDE 6.1 and Telegram, have already implemented this and will raise web browser windows when you click links. Others, like Discord, have not implemented this yet by default.

For KDE Specifically, you may be able to force it in the case of Discord and some other apps by adding the variable XDG_ACTIVATION_TOKEN=kwin-1 before the program you’re trying to launch in the terminal. In some cases, this may provided a workaround, but not guaranteed.

Ultimately, each individual app needs to support this protocol upstream and have their own activation tokens to avoid raising the incorrect windows."

https://forum.manjaro.org/t/firefox-doesnt-raise-window-after-clicking-a-link-on-wayland/154842/38

I wanted to correct my statement above, about Firefox taking a step. Firefox already implemented it, so now it's up to other app developers to fix it.
I'm not sure if the bug should be opened, since there is no more action to take on mozlilla's site, unless it will somehow participate in an information campaign to app developers to implement it? I doubt it, but there is no harm in asking ;).

All you need is to install this GNOME extension - https://extensions.gnome.org/extension/6385/steal-my-focus-window/
Firefox implements everything needed, what you see here it Mutter focus stealing mechanism.
(https://gitlab.gnome.org/GNOME/mutter/-/issues/673)

Gnome extensions don't work outside Gnome DE, so that is not a general solution.
Speaking of KDE, official implementation works in Kwin, Firefox has it as well, so at this point other apps that expose links must implement it, and it's from us - users, to report it and point in the right direction.

For reference, the relevant KDE bug is https://bugs.kde.org/show_bug.cgi?id=424795. It links to https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/50, xdg_activation protocol – merged three years ago. It seems that this protocol needs to be supported on both ends of a transaction, meaning that Firefox needs to support being activated.

This should be a duplicate of bug 1692119. Except: the activation still doesn’t work for me clicking a link in Thunderbird that opens in Firefox (Fedora 40 with Wayland, Thunderbird 115.10.1, Firefox 126.0). Presumably, this scenario is supposed to be working.

Does it work with any other Wayland application under KDE? Can you give me any example I can check?
Thanks.

Never mind. The issue is that Thunderbird is still on the 115 branch, so Wayland support isn’t activated by default. Running Thunderbird with MOZ_ENABLE_WAYLAND=1 environment variable fixes this, it will set XDG_ACTIVATION_TOKEN environment variable then.

I would say that's actually a major security issue for a browser. Any external app can open a browser new tab without the user noticing it because that external app decided so. It's the exact same concern as preventing popup opening without user interactions. The new tab could be compromised and start creating issue long before the user notice it

I’d say that an external app with the capability of opening a URL in Firefox doesn’t need to open a new browser tab in order to cause trouble. The system is already compromised at this point.

Not if it's a link in an email or another document or just some basic IM wrapper. They're are pletoraw of app that could display a link that would end up being open in an existing browser, not all of them are going to properly implement said requirement, but in the end it's the browser that really open the real security issue, not the app were a link is clicked.

I can confirm that Thunderbird as Wayland window opens links in Wayland Firefox moving to the top. Libreoffice didn't implement it yet.

As a normal user, I value functionality as well, so it shouldn't be that security goes in the way. I am not running Tails or Cubes or whatever extremely safe distro for a reason. They are hardly usable, and I'm not a diplomat or politician. Those should probably mandatory use such system, because they get hacked pretty often, but not because of the software, but because of their actions. Human is the security hole that can't be patched.

My workflow currently requires clicking on dozens of links in spreadsheet and in company mails, to open certain resources. This is HUNDREDS of clicks every day. Now, if those clicks are not raising the browser to the top, I have to do it manually anyway. So I have to do hundreds of additional actions just in the name of security, for a case that I never experienced in over 30 years of using computers (including Windows)?

COMPUTERS ARE TOOLS and if security makes them broken, then what is the point of the security in the first place? Let's not get crazy. Certain features are needed. If this is a security problem then sometimes there is no solution, or maybe there is, but not a simple one. Cutting out a basic feature just for security’s sake is like imprisoning someone, just because it's not safe outside. It's also a lazy solution.

Linus' holy commandment is: "Thou shall not break user space" ;).

Anyway, all is well implemented on Firefox's side, so the topic could be closed.

The security issue is to not raise to top so in this case it goes hand in hand with usability. We cannot rely on calling app to implement anything on there side, the browser HAS to go to top of it open something

I am on KDE 6.1 (Kubuntu 24.10) with Firefox Snap and Thunderbird flatpak (v128.3.1esr; it's showing Wayland as Window Protocol in Troubleshooting). If Firefox is closed, then clicking a link in thunderbird opens firefox raised to top, however, if Firefox is in the background, clicking on a link in thunderbird opens the link in the firefox, but does not focus the Firefox window.

Shouldn't this already work according to the previous messages in this thread?

Yes, it should, and it works that way for native programs. Probably containers like flapacks or snaps behave differently and a new set of rules must be made for those (if possible).

Since this report was about native apps, this is a different issue. I can't tell if Mozilla is able to utilize some existing setting to make it work in flatpack or maybe a new Wayland protocol, or xdg protocol is needed?

Still, aside FIrefox and Thunderbird native installs, the rest still hasn't implemented it and links clicked from those apps, are not raising FF to the top, so the whole situation is still problematic, but at least this case here is resolved.

I'm still having trouble with this. On KDE Plasma 6.2.3 under Wayland, opening a link in most programs will not raise Firefox to the front (it did work with Thunderbird). If I set a Chromium-based browser as my default, it will raise to the front just fine. Reading this thread as well as the one on the Manjaro forum, I'm unable to figure out whether this is a Firefox issue or a me issue. I really wouldn't want to use a Chromium-based browser just to get around this issue, but it is a rather annoying one.

I suppose I should give a little more detail, since I still have this problem:

If I open a URL by clicking a link in a program such as Discord, HexChat, or Okular, the link opens in Firefox but Firefox remains in the background.
If I open a URL in a terminal with xdg-open <url>, the link opens in Firefox but Firefox remains in the background.
If I open a URL in a terminal with firefox <url>, the link opens in Firefox but Firefox remains in the background.
If I open a .html file with Dolphin by right-clicking it and selecting "Open with Firefox," the link opens in Firefox but Firefox remains in the background.
If I open a .html file with Dolphin by double-clicking the file, the link opens in Firefox AND Firefox is raised to the foreground. (Huh? What's different?)

In each case, if a Chromium-based browser is the default, the link opens in Chromium and Chromium is raised to the foreground (substituting the firefox command for the chromium command when appropriate). This is the desired behaviour.

Has anyone been able to figure this out?

Afaict the way of doing this is supporting XDG_ACTIVATION_TOKEN and xdg-activation-v1. Part of the issue is that the app launching firefox is responsible of transferring the activation so that firefox can raise itself. But there might be a bug in our implementation?

Bug 1767546 and such are related. Afaict, https://bugzilla.mozilla.org/show_bug.cgi?id=1767546#c5 and such still work, and firefox gets raised properly if I do that.

I installed foot and used the url-mode, and it did indeed raise Firefox. The foot documentation says this simply invokes xdg-open on the URL, but manually typing xdg-open <url> within foot does not raise Firefox. I'm not sure how to troubleshoot this even in theory, since there shouldn't be any difference between these two.

If I open a .html file with Dolphin by right-clicking it and selecting "Open with Firefox," the link opens in Firefox but Firefox remains in the background.
If I open a .html file with Dolphin by double-clicking the file, the link opens in Firefox AND Firefox is raised to the foreground. (Huh? What's different?)

I tried running WAYLAND_DEBUG=1 firefox and comparing right-clicking vs. double-clicking a file. Right-clicking fails to focus Firefox:

[  97594.245] {Default Queue}  -> wl_surface#66.frame(new id wl_callback#72)
[  97594.278] {Default Queue}  -> wl_surface#66.commit()
[  97648.955] {Default Queue}  -> xdg_activation_v1#18.get_activation_token(new id xdg_activation_token_v1#55)
[  97648.988]  -> xdg_activation_token_v1#55.set_serial(83453, wl_seat#22)
[  97648.999]  -> xdg_activation_token_v1#55.commit()
[  97649.440] xdg_activation_token_v1#55.done("not-granted-666")
[  97649.456]  -> xdg_activation_token_v1#55.destroy()
[  97649.463] {Default Queue}  -> xdg_activation_v1#18.activate("not-granted-666", wl_surface#33)
[  97649.477] {Default Queue}  -> xdg_activation_v1#45.activate("not-granted-666", wl_surface#33)
[  97664.365] {Display Queue} wl_display#1.delete_id(55)
[  97664.386] {Display Queue} wl_display#1.delete_id(72)
[  97664.396] {Default Queue} wl_callback#72.done(20228754)

Double-clicking works:

[ 125321.497] {Default Queue}  -> wl_surface#66.frame(new id wl_callback#72)
[ 125321.518] {Default Queue}  -> wl_surface#66.commit()
[ 125347.562] {Default Queue}  -> xdg_activation_v1#18.get_activation_token(new id xdg_activation_token_v1#71)
[ 125347.587]  -> xdg_activation_token_v1#71.set_serial(83453, wl_seat#22)
[ 125347.595]  -> xdg_activation_token_v1#71.commit()
[ 125347.912] xdg_activation_token_v1#71.done("not-granted-666")
[ 125347.941]  -> xdg_activation_token_v1#71.destroy()
[ 125347.948] {Default Queue}  -> xdg_activation_v1#18.activate("not-granted-666", wl_surface#33)
[ 125347.959] {Default Queue}  -> xdg_activation_v1#45.activate("kwin-187", wl_surface#33)
[ 125370.805] {Display Queue} wl_display#1.delete_id(71)
[ 125370.841] {Display Queue} wl_display#1.delete_id(72)
[ 125370.850] {Default Queue} xdg_wm_base#28.ping(83983)
[ 125370.860] {Default Queue}  -> xdg_wm_base#28.pong(83983)
...
[ 125371.152] {Default Queue} wl_callback#72.done(20256453)

I'm not sure how Firefox learns to activate itself using the kwin-187 token. If I restart Firefox with WAYLAND_DEBUG=1 firefox 2>&1 | rg kwin and open a HTML file, I only ever see xdg_activation_v1#45.activate("kwin-192", wl_surface#33), and 192 appears nowhere earlier in the log.

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