Firefox - doesn't raise window after clicking a link on Wayland

I spoke to Nate Graham, and he suspects that this is a bad Wayland implementation, because he doesn’t have a problem with the apps he uses, but didn’t tell which apps he meant.

On the other hand, if the issue is true for all other Wayland apps, then it would mean that the problem is with Wayland itself. On the other hand, if that was some known Wayland limitation, Nate would know, unless this is a new thing, that hardly anyone knows about. Links are usually opened by browsers and the only native Wayland browser is Firefox since 19.12.2023, so it is possible that the issue was not put into light.

@ybeltukov, what do you mean when you say about opening LO document twice? I want to check if I can replicate it.

@michaldybczak I have the following issue with LO:

  1. open a document
  2. minimize it
  3. open the document the second time. Nothing happens to me (the existing window is not raised)

By the way, one can enable the native Wayland support for Chromium (by selecting Ozone platform in chrome://flags/). In this case, I have the same issue as with Firefox.

1 Like

This is how LO always worked, even on X11. It’s not allowing for opening the same document more times, and the window is not even alerted. I’m working with LO regularly and I learned a long time ago, that when nothing happens on clicking a document, I already have it opened.

I cannot confirm this issue after testing the current version 23.1.2-240102 of Manjaro KDE live Wayland session and Firefox v121 running on native Wayland on my device and VM.

I doubt if the issue is related to your proprietary Nvidia driver not being friends with Wayland.
PS: I am using the AMD driver.

I do have Nvidia, but the desktop runs on integrated Intel anyway, and the other computer I tested was on AMD integrated graphics. So you are right, this is not tied to graphical drivers. Besides, this is not a visual bug but a window behavior bug.

Note, that when FF is not opened and link is clicked, it opens to the foreground without problems for the first time. Only when it is already opened, it won’t come.

I used Live on Virtualbox, if that matters. It’s mind-boggling that this is not replicable every time, but still, I’m not the only one seeing this issue, and it may happen on very vanilla installs or in live sessions, so this is not some user customization. Strange.

I updated Manjaro stable yesterday and nothing has changed.

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

$ google-chrome-stable --enable-features=UseOzonePlatform --ozone-platform=wayland
$ 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.

Where do I report Wayland issues?

For those interested in checking it:

  1. Open a browser (any browser) as native Wayland window.
  2. Check with Kwin debug console if it’s really a Wayland one.
  3. Open Thunderbird or Libre Office Writer with links, click on them.

Kwin debug console opens with this command:
dbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole

Again, a browser must be already opened and in Wayland mode.

In many tests, this was replicable 100%.

Also, see the site:

and note the @Shawn’s comment:

"Wondering why links in external applications wont launch when wayland is set in Chromium. Clicking a link in email or dolphin flashes the icon orange if the browser is open and/or minified.

This doesn’t occur when X11 is set in Chromium, just wayland."

Doesn’t it remind you my exact issue? :wink:

I’m having the same problem as @michaldybczak described on my Manjaro KDE installation. I’m pretty sure it’s since the Firefox update which defaults to Wayland. I had used FF on XWayland before and had no problems with it under Wayland.

I have now tried with MOZ_ENABLE_WAYLAND=0 to force it not to use Wayland (confirmed by the dbus command above), but that didn’t solve the original issue on my system.
(But at least I can now use KeepassXC again. \o/)

I made all my browsers to launch in native Wayland: Firefox, Chrome, Chromium, Vivaldi, Edge - after that they all show the same behavior.

For me, it’s clear that this is how currently it works in Wayland. Someone said (I don’t remember where) that this was by design to prevent some malicious apps to still the top layer. I’m not sure how is your experience, but I have never seen such thing in my entire life and I use computers since early 90ties. This is a clear example of throwing baby with a bathwater. To secure some fringe and unlikely happening, the commonly used feature was disabled…

@michaldybczak : thank you so much for the precise qualification and hard testing. I was trying KD6 after years of enlightenment, and that issue is driving me crazy. I thought it was a KDE problem, and thanks to you, I now know that it is much worse. I think I hate wayland for that.

Did you find a place to report the problem or vote for it? It is really making my life harder, to the point were I’m questionning remaining to wayland (and no, it’s not a long term solution).

Seems to depend on ~something~ because here on KDE6 wayland
I was just able to click a link in telegram and it raised firefox.
“Open hyperlink” in libreoffice-writer however failed to do so.

If FF or any Wayland windowed browser is closed, the first click raises it to the top. The next ones are not. Or was it not the first click in your case? I haven’t seen any exception so far.

I have reported it on Firefox, but then marked it as an upstream issue. I was said to leave it open, so the FF bugtracker team could follow the development on that front.

Unfortunately, I haven’t reported it to Wayland. I’m not sure where to report it in the first place.

Me too, but I have to say, that I got used to it in the meantime. It’s bad, but there are worse things that I have on my mind, so I am ignoring it for now.

I did more research, and now it seems to have been added in wayland (arf, I can’t include link? Does that works?

seems to be that part of the spec:

It was added last week to futur gnome 46:

It is said to be in QT6, so it should come at some point of KDE6 I believe

(and yes I found your issue on mozilla bugzilla)

1 Like

Both cases were with a well used firefox session minimized.
It was repeatable - every click in telegram would raise ff.
Looking for other places to click links … I found one in smplayer menus, and that would fail to raise ff like LO.

1 Like

Yes, as usual Wayland requires a protocol for what previously was a simple thing. And then that has to be implemented by every DE and application. I understand the security issues and that we need something better than X11 but ffs.

Anyway be glad it is getting done (still in staging right now which is probably why DE’s haven’t bothered yet), look at how long it took to get Wayland screen sharing working properly :stuck_out_tongue:

1 Like

Yesterday, I noticed that Firefox started raising windows when links in Thunderbird were clicked!
Unfortunately, when links are clicked from LibreOffice, it still behaves in the old way (no raising to the top).
I checked Plasma debug console to ensure that Firefox is still Wayland and it is.

I’m on Manjaro unstable and yesterday was a very small update:

[2024-03-12T07:18:14+0100] [ALPM] upgraded python-pyparsing (3.1.1-1 -> 3.1.2-1)
[2024-03-12T07:18:14+0100] [ALPM] upgraded postgresql-libs (16.1-6 -> 16.2-1)
[2024-03-12T07:18:14+0100] [ALPM] upgraded plasma-workspace (6.0.1-1 -> 6.0.1-2)
[2024-03-12T07:18:13+0100] [ALPM] upgraded openssh (9.6p1-3 -> 9.7p1-1)
[2024-03-12T07:18:13+0100] [ALPM] upgraded libunwind (1.7.2-1 -> 1.8.1-1)
[2024-03-12T07:18:13+0100] [ALPM] upgraded libqalculate (4.9.0-2 -> 5.0.0-1)
[2024-03-12T07:18:13+0100] [ALPM] upgraded lib32-libunistring (1.1-1 -> 1.2-1)
[2024-03-12T07:18:13+0100] [ALPM] upgraded fwupd (1.9.14-1 -> 1.9.15-1)
[2024-03-12T07:18:12+0100] [ALPM] upgraded gnupg (2.4.4-1 -> 2.4.5-1)
[2024-03-12T07:18:12+0100] [ALPM] upgraded shadow (4.14.6-1 -> 4.15.0-1)
[2024-03-12T07:18:12+0100] [ALPM] upgraded libunistring (1.1-2 -> 1.2-1)

None of them seems to have anything to do with the issue… unless it’s plasma-workspace 6.0.1 that modified it somehow.

Now I need to test other browsers, but so far it only works with links from Thunderbird. Weird.

Hi, same problem happened to me on Arch since a recent update (plasma 6, from X11 to Wayland).

This problem occurs not only on Firefox but also on Emacs. I always use commands like emacsclient -n filename to open files in an existing Emacs window and raise it to the top. But now the files only open in background.

Since searching for this issue with links not raising the window in google is resulting in this post coming up, 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:

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.


Ah, that is why it works in Thunderbird since few months. I forwarded your info to mozilla bugtracker:

in case someone looked there as well.
I guess, now it’s up to users to call this bug to each app that has/uses/shows links with the link to this topic, specifically to the info you kindly provided.
Maybe I post a bug to Libreoffice, when I find some time.