SUMMARY Browser does load the link, it's just it's window is not activated STEPS TO REPRODUCE 1. Open some link in konsole via it's "Open Link" context menu action. OBSERVED RESULT It seems like nothing happens. Actually, the link is opened in browser on background plane. EXPECTED RESULT Browser window with loaded link should bring to first plane. Operating System: Ubuntu 20.04 KDE Plasma Version: 5.19.80 KDE Frameworks Version: 5.73.0 Qt Version: 5.14.2
Confirmed, I believe this is a known issue but I don't know which bug is tracking it.
It is a known issue, there is no specification to do this. GTK use a custom one which doesn't help anyone.
So someone has to propose one and then all the compositors have to implement it?
and all toolkits
Is the custom GNOME implementation upstreamable, or would we/someone need to start from scratch?
*** Bug 427445 has been marked as a duplicate of this bug. ***
Can anyone please inform us about this bug? is there any work behind this? In fact, I personally would be fine if some hacks belonging to gnome, kde or wlroots (doesnt matter) were used to solve this problem.
Yes, a cross-desktop protocol is being worked on upstream: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/50
*** Bug 432913 has been marked as a duplicate of this bug. ***
Since the Wayland protocol has been merged, this isn't blocked by anything anymore and we can implement support on our side.
I don't know why this was reopened. We know we don't support this yet.
Because with the activation protocol merged upstream, we now can, and having a bug report open to track that work is reasonable.
*** Bug 439567 has been marked as a duplicate of this bug. ***
*** Bug 440032 has been marked as a duplicate of this bug. ***
*** Bug 441866 has been marked as a duplicate of this bug. ***
This has changed a lot in 5.23. It won't fix everything at once, but leaving this open won't help with that.
I haven't noticed any changes in git master here. What specific changes need to be implemented to make it work in apps? Where should bug reports be filed?
OK, I have begun to file bug reports on individual use case which are still broken (for me, all of them): Bug 442264 Bug 442265 Bug 442266 Bug 442267 Bug 442268 Bug 442269 Should I continue? Is this useful?
>Is this useful? Not really. It's only useful if the receiving software is known to have activation support. Otherwise they need to be adjusted before we can start investigating any potential issues on our side.
So literally every app/toolkit needs to be changed to opt into the activation protocol? I fear that this is going to feel broken forever... :(
This bug is still reproducible on Plasma 5.23 beta even with KDE software. 1. open a text file with Kate via Dolphin 2. minimize Kate 3. open another text file with Kate via Dolphin Result: Kate is still minimized
KDE apps won't be fixed until activation support ia added into Qt. It's still in progress; see https://codereview.qt-project.org/c/qt/qtwayland/+/321246
*** Bug 444357 has been marked as a duplicate of this bug. ***
*** Bug 445128 has been marked as a duplicate of this bug. ***
*** Bug 448671 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #22) > KDE apps won't be fixed until activation support ia added into Qt. It's > still in progress; see > https://codereview.qt-project.org/c/qt/qtwayland/+/321246 It's merged, but I can still reproduce 5.24.80 on KDE Neon Unstable see #448671.
That's only in Qt6. Perhaps we should look into backporting it in our patch collection. It's a pretty huge change though, and stretches the definition of a bugfix. If fixing a bug required adding a major new feature, is it really a bugfix?
Strawberry music player is built against Qt 6 on Arch Linux and this bug is reproducible with it.
(In reply to Patrick Silva from comment #28) > Strawberry music player is built against Qt 6 on Arch Linux and this bug is > reproducible with it. Is it using Qt6 with the patch (which I guess is Qt6 master)?
I do not know. Which Qt version will include this fix/feature?
(In reply to Patrick Silva from comment #30) > I do not know. Which Qt version will include this fix/feature? Probably 6.3.0
Both the sending and receiving apps need to implement activation support, or be using a toolkit that does it automatically. It's not enough for one of the apps to be using a compatible version of Qt6; the other app that sent the activation request have to be using it, too. So currently this will only reliably work between Qt6 apps, or GTK4 apps, or between GTK4 and Qt6 apps. It sucks, I know. I'm somewhat baffled baffled by the fact that this wasn't, like, built into the core Wayland protocol. But it is what it is, and at least thanks To Aleix, we have it now.
Thanks for clarifying Nate. Probably we will have many duplicates of this bug in the next years.
Indeed. :(
(In reply to Nate Graham from comment #32) > It sucks, I know. I'm somewhat baffled baffled by the fact that this wasn't, > like, built into the core Wayland protocol. Just to understand the situation: Has this been built into the (core) Wayland protocol by now or if not, wouldn't it make sense to put it in there now, as of "better later than never"?
(In reply to postix from comment #35) > Just to understand the situation: Has this been built into the (core) > Wayland protocol by now or if not, wouldn't it make sense to put it in there > now, as of "better later than never"? So Wayland 2.0?
The activation protocol was done as an extension to the core protocol. I don't know if the core protocol itself is still open for changes. Someone who understands Wayland better than me would have to answer that question.
*** Bug 450926 has been marked as a duplicate of this bug. ***
*** Bug 451377 has been marked as a duplicate of this bug. ***
*** Bug 451504 has been marked as a duplicate of this bug. ***
Hello, are there any news about this? It's quite annoying. I have a Dolphin window already open but minimised, I download a file in Firefox, click on the "Open containing folder" in Firefox and all I get is a blinking Dolphin icon in the Task Manager. Hopefully after 2 years Wayland/QT have evolved enough to finally address this? Thanks 🙏 P.S. is the "RESOLVED" status really appropriate here?
In that case, it's caused by Firefox not properly implementing the Wayland activation protocol. This isn't a general issue, it's a series of app-specific issues.
(In reply to Nate Graham from comment #42) > In that case, it's caused by Firefox not properly implementing the Wayland > activation protocol. > > This isn't a general issue, it's a series of app-specific issues. I get the same behavior even by repeatedly calling i.e. "xdg-open ~/Downloads": first call is opening a new Dolphin instance, and if i cover it by another window the subsequent calls do not bring Dolphin to foreground, only the icon in Task Manager gets highlighted.
(In reply to bakatrouble from comment #43) > (In reply to Nate Graham from comment #42) > > In that case, it's caused by Firefox not properly implementing the Wayland > > activation protocol. > > > > This isn't a general issue, it's a series of app-specific issues. > > I get the same behavior even by repeatedly calling i.e. "xdg-open > ~/Downloads": first call is opening a new Dolphin instance, and if i cover > it by another window the subsequent calls do not bring Dolphin to > foreground, only the icon in Task Manager gets highlighted. Can confirm Plasma 6.2.4
That's an issue in Konsole (or whatever terminal app you're using) failing to forward an activation token to xdg-open (and then internally to kde-open). This needs a new bug report; it's not a generic issue.
(In reply to Nate Graham from comment #45) > That's an issue in Konsole (or whatever terminal app you're using) failing > to forward an activation token to xdg-open (and then internally to > kde-open). This needs a new bug report; it's not a generic issue. This sounds like bug #442265
(In reply to Nate Graham from comment #45) > That's an issue in Konsole (or whatever terminal app you're using) failing > to forward an activation token to xdg-open (and then internally to > kde-open). This needs a new bug report; it's not a generic issue. So this is a main issue for my use cases - I automate my desktop use cases using scripts, and the inability of a script to start a foreground application, or - more problematic - raise an existing window, is a serious usability problem on kwin Wayland. Why can't kde-open talk to kwin and get an activation token? Why for that matter isn't there a scriptable dbus API to ask for and get an activation token without owning the focused window? There is a working hack where you can create a new window, use it to get an activation token, then immediately close it. This is much more destructive to the user experience than letting applications activate windows when it makes sense to do it: kde-open is one such case, an application responding to a global hot key (see yakuake) is another.
(In reply to postix from comment #46) > (In reply to Nate Graham from comment #45) > > That's an issue in Konsole (or whatever terminal app you're using) failing > > to forward an activation token to xdg-open (and then internally to > > kde-open). This needs a new bug report; it's not a generic issue. > > This sounds like bug #442265 Yes indeed, good find. (In reply to Oded Arbel from comment #47) > Why can't kde-open talk to kwin and get an activation token? > Why for that matter isn't there a scriptable dbus API > to ask for and get an activation token without owning the focused window? The Wayland protocol requires that only a GUI app with a visible window can request a token. I don't have context on where this requirement comes from, but it's in the protocol. For the moment, let's focus on getting Bug 442265 fixed.