Apps can't raise windows on Wayland, something we've take for granted in desktop computing since forever

Community
1

Is there anything that can be done about this? I can’t believe that after 15 years, with x11 being depreciated literally everywhere as “completely outdated,” something so basic is still not implemented anywhere outside the desktop evironments - no apps actually support it. The ability to raise windows wasn’t even implemented in Wayland until a few years ago when it was already getting rolled out everywhere and people realized that it can’t do rudimentary things a desktop is supposed to do. So they belatedly implemented it as an “extension” four years ago with the result that we still don’t have something so basic as “if an app opens a new tab in chromium, chromium window should be raised” something every desktop environment has implemented since the dawn of desktop environments.

If this is wayland after nearly two decades of development, with x11 being depreciated everywhere, I honestly don’t know what to say. Like maybe Wayland should’ve remained a protocol for Linux automotive, or Linux mobile, or whatever else the perpetual “next big thing” that nobody uses is, since quite obviously it was never designed with basic desktop usage in mind. Pretty much everything you need specifically for the desktop (remote access, sound, decorations, window management etc. was grafted on later as an “extension”). It’s like building a car and designing the steering wheel as optional addin ten years later lol.

2

Filing bug reports with the applications that don’t support it.

Window activation has been a standard protocol for quire some time now, it is implemented by all the major desktop compositors and major toolkits (Qt, GTK).

There can be cases in which API is not called correctly or hard to solve corner cases, e.g. activating from a shell environment running inside a terminal window.

Most Wayland apps should have this as part of their application framework, e.g. Qt, GTK, Chromium/Electron.

There can of course be code paths in which applications bypass the provided functionality and which might not have been properly updated yet.

It was obviously designed to enable the desktop use case as it would otherwise not have gained any traction at all.

The chosen architecture provides the flexibility to support a wide range of use cases without burdening simpler ones with unnecessary (and often unwanted) complexity.

The core infrastructure defines how clients and server communicate “on the wire” as well as how common objects are being addressed and communicated.

For each use case this is then augmented by higher level infrastructure to sharing data and functionality without having to reinvent the lower parts.

A very common approach in software engineering, especially when involving communication.

For example the “Internet” is composed of several such layers, from electrical and/or radio signalling, over packet routing to use case specific protocols like HTTP.

Pretty much the same as X11, e.g. the EMWH extension for window management, DRI3 for GPU buffer sharing or RANDR for output configuration and control.

Right now my system has the following 31 X11 extensions instlaled

libxcb-composite.so.0.0.0
libxcb-cursor.so.0.0.0
libxcb-damage.so.0.0.0
libxcb-dpms.so.0.0.0
libxcb-dri2.so.0.0.0
libxcb-dri3.so.0.1.0
libxcb-ewmh.so.2.0.0
libxcb-glx.so.0.0.0
libxcb-icccm.so.4.0.0
libxcb-image.so.0.0.0
libxcb-keysyms.so.1.0.0
libxcb-present.so.0.0.0
libxcb-randr.so.0.1.0
libxcb-record.so.0.0.0
libxcb-render.so.0.0.0
libxcb-render-util.so.0.0.0
libxcb-res.so.0.0.0
libxcb-screensaver.so.0.0.0
libxcb-shape.so.0.0.0
libxcb-shm.so.0.0.0
libxcb-sync.so.1.0.0
libxcb-util.so.1.0.0
libxcb-xf86dri.so.0.0.0
libxcb-xfixes.so.0.0.0
libxcb-xinerama.so.0.0.0
libxcb-xinput.so.0.1.0
libxcb-xkb.so.1.0.0
libxcb-xrm.so.0.0.0
libxcb-xtest.so.0.0.0
libxcb-xvmc.so.0.0.0
libxcb-xv.so.0.0.0
5 Likes
3

Wow, heck of a title… slightly overstated though, I think.

If I click a link in Thunderbird, Firefox zooms into view - so apps obviously CAN raise windows.

I’m more concerned that we lost mouse gestures; they made a fundamental and complete shift in the way I interact with my desktop (so much better than traditional interactions…) meaning that anything you can do with a keyboard shortcut, or a script, or clicking a button - I could find a way to mimic that and execute it by drawing a shape on screen… totally minimising the times you have to shift hand between mouse and keyboard.

1 Like
4

On my system no apps support it. Maybe it needs flatpak?

I’ve tried with Chromium and Kate, regular packages on Arch. So you open a file from dolphin in Kate, a new tab is created but the window doesn’t get raised. Or you open Kate help, it opens a new chrome tab, but the window remains in the background. For a while I thought Kate help was bugged eventually put two and two together and realized it’s a Wayland issue. I suppose a workaround would be to force opening new windows until the xdg-activation-v1 extension is actually implemented in the apps, because the way it is now is frankly - and I hope nobody takes it as an insult because it’s just a fact - unacceptable.

5

Open help on Kate. Make sure you have firefox already open. Does the browser window get raised?

BTW Gestures are well supported on KDE wayland, there’s even some package for configuring advanced gestures.

6

Screenshot_20251012_223252
Screenshot_20251012_2232521397×391 212 KB

Yes.

As for Mouse Gestures, I suspect you don’t understand what that means… and it certainly is not the same (or as limited) as touchpad or touchscreen gestures.

I used Easystroke for quite a number of years before finding out I could do most of what that app did in Plasma - but it was removed along with the old hotkeys settings.

You can get a feel for mouse gestures (something implemented many many years ago in Opera, and Firefox browsers - and still available to use in Vivaldi and Firefox - try it: Gesturefly

Then imagine you can use gestures also for tabs in Dolphin, or many other apps - for raising, swapping/minimising/maximising horizontal/vertical without having to click corner icons or whatever.

2 Likes
7

What exactly does that mean in terms of versions?
And what is your focus stealing prevention setting?

Window activation is not related to the type of installation, i.e. it should work the same regardless of whether either the launcher or the target are inside or outside a sandbix

1 Like
8

Here’s what I found: It floats but doesn’t float above the active window from where you opened the help. It sometimes floats above other windows, but never above the window from which you opened the link. The icon in the task manager does change color, so clearly there is awareness that firefox … did something in the background.

Operating System: CachyOS Linux
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.18.0
Qt Version: 6.10.0
Kernel Version: 6.17.1-2-cachyos (64-bit)
Graphics Platform: Wayland
Graphics Processor: Intel® HD Graphics 4600

As for focus stealing prevention, yes I already looked there and set it to none in the hopes of solving the issue.

9

this sounds like focus stealing is screwed down too tight, but you say that’s set to none so,

what are the other settings are you using?

1 Like
10

The “None” mode is broken in 6.4 with a fix expected in 6.5:

1 Like
11

The entire universe isn’t generally broken here; this is most likely a case of individual bugs. And there are definitely some issues with this working properly depending on the combination of apps. Each case needs a bug report, basically.

If *literally nothing* works, it might be a case of some kind of local misconfiguration. I’d recommend trying with a new clean user account on the system and seeing if it still happens there.

2 Likes
12

Thanks!

Until today, I did wrongly assume that it was a general issue with Wayland, because I use Firefox (with the Simple Tab Groups extension) so much more than any other application.

With the extension configured to automatically open FreshPorts URLs in a FreshPorts group in a separate window that is already open:

https://www.freshports.org/ports-mgmt/pkg/#history

Control-click to open the page in a new tab:

  1. the tab automatically moves to the required window
  2. a notification invites me to click to bring the tab to the front
  3. Wayland only, clicking is not effective

– I get the change of colour in task manager, then I must use the manager to bring the window to the front.

I’m fairly certain that I can also trigger the issue – a change of colour in task manager, without bringing the window into focus (front/top) – in some other way, but right now, I can’t think of it. Maybe my memory playing tricks on me.

No bug when I open an https:// URL from within apps such as Konsole and Thunderbird.

1 Like
14

One app that is absolutely notorious for this kind of behavior and went from being most useful to frustrating is Yakuake. Pressing the shortcut key does not always work which is probably the most infuriating behavior one could expect. Sometimes it works, sometimes it doesn’t. It feels random.

Also, clicking on notifications that should otherwise open a window could also display the same behavior.

This is one of those issues that really need addressing.

I am grateful KDE Plasma is what it is (bugs and all). It does (to be honest here) feel more and more solid as time goes by. It has its moments but overall, it’s a ridiculously amazing project.

1 Like
15

This doesn’t sound like the same issue. Can you open a detailed bug report about it on https://bugs.kde.org? Make sure to follow and fill in the template.

16

The op is referring to windows that don’t come to the top when they should? Yakuake, Telegram and some others do in fact have these problems. Sometimes they work, then for whatever reason, they simply break.

Yakuake just happens to be the most notorious one to break on my system. It’s like this, pressing F12 always toggles Yakuake (to show or hide) and on every new boot it works for a bit. Then it just dies and stops coming to the top. On X11 this worked 100% of the time and is what made it so convenient to use. If I resize any windows sitting on top of Yakuake (enough to see Yakuake behind them), pressing F12 does in fact toggle it, but it’ll never raise to the top.

Yakuake is not forced to stay behind them and no other window is forced to stay on top.

Clicking on notifications to raise up Telegram also work for a bit (100% on X11), then clicking on them at some point will break and clicking on notifications will no longer raise Telegram.

Is this really not the ops issue?

17

Correct. The OP’s issue is when one app does something that should cause another one to raise its window to handle that thing. Most commonly, opening a link and expecting the running web browser to and open that link and raise itself, or opening a file and expecting another running app to open the file and raise itself.

If Yakuake fails to raise itself as a result of pressing F12, that’s a different thing.

18

Hmm, what this smells to me like is: Yakuake for some forsaken reason defaults to (or used to) enabling the option “Keep window open when it loses focus”. So what I’d often see is: you’d click away from Yakuake window to raise some maximized window behind its back. You forget about Yakuake and carry on with your work. Then you want to bring up Yakuake again. You press F12, but nothing happens. What actually happened was that the Yakuake window was still opened in the background and that F12 press actually dismissed it, with only the second press of F12 being able to open it once again.

^This is an old experience though, so there’s a chance this was fixed by now, but maybe not. What Yakuake should do to fix it would be to:

  1. Disable that option by default, ugh
  2. And then even if it is enabled, F12 should always bring up Yakuake window into focus if it currently isn’t in focus, even if the window wasn’t actually dismissed and hidden (unless the Yakuake’s window isn’t obstructed by anything else AND the mouse cursor is on the same screen as said window)

It’s just one of those UX nitpicks with default options that I can’t believe weren’t fixed yet, since they seem so obvious. Another one is how Dolphin defaults to both opening a new window instead of new tabs in existing windows PLUS restoring previous tabs, so you end up with multiple windows that have all duplicated tabs from the previous one + that newly opened one, which makes zero sense logically and is very messy.

This actually makes me want to just go and put out patches fixing all of this nonsense one by one, I just couldn’t get a dev environment set up neither on my Arch setup with kde-builder nor with KDE Linux that’s somehow missing the utility commands to set it up from its wiki…

(Though your next message and implying it works on X11 does suggest it’s a different issue I guess…)

I’m having similar issues with clicking on notifications most notably with Thunderbird, I think it possibly just never works. Telegram I’m not sure, it definitely works at least sometimes, not sure how often it’s broken (but I don’t feel like it’d always work either).

You example with Kate help link and Firefox works for me, Firefox does get brought up.

What doesn’t work most notably: opening a text file from Dolphin in an existing Kate window. Which is wild, because one would expect that sort of thing to at least work flawlessly within KDE’s own apps, right? Same thing happens if you click on the “Show in Folder” in Firefox next to a downloaded file. The Dolphin window gets yellow in the taskbar, but isn’t brought up. I’ll be seeing if this is fixed in 6.5.