Created attachment 178639 [details]
the issue

Sorry for hand recording but I don't know how else can I record the screen recording app.

Can reproduce. Unsure how much we can do to prevent this, though.

It is preventable by using Layershell on Wayland to force Spectacle's region selection windows to stay above other windows no matter what. I have chosen not to do that for 2 reasons:

1. If Spectacle's region selection windows froze for some reason, users would be unable to switch away from Spectacle if I used Layershell. Only the overlay that puts a dashed outline around an actively recorded region uses Layershell because you can click through the overlay. Spectacle's region selection windows are just normal fullscreen windows.

2. It is sometimes useful to be able to alt+tab to another app and return to Spectacle's region selection windows, but that's a less important reason.

Even if it's intentional, it doesn't make it less of a bug. You don't have this on X11.
That's a tradeoff, sure. But it is clearly not what you'd expect when you make a screenshot.

You guys always push to try wayland and over the last 5 years since 5.17 it's still always stuff like that that clearly shouldn't happen but "it's indended", "it's the drivers", "apps should fix that".

While you can't really blame DE for misbehaving 3rd party software, it is just not right when stuff like this happen with 1st party apps and not being considered a bug at all. It's not just KDE, to be fair. GNOME does shit like this too with libadwaita removing theming support, purging icons or not supporting server side decoration.

(In reply to Noah Davis from comment #3)
> 1. If Spectacle's region selection windows froze for some reason, users
> would be unable to switch away from Spectacle if I used Layershell.

Wouldn't this be possible to prevent by having 2 separate threads (or processes) one of which acts like a watchdog. Then thread that created layershell might be destroyed by watchdog thread if the latter does not receive the signal.

(In reply to gudvinr+kde from comment #4)
> You don't have this on X11.

No, on X11 I'd have to make the same tradeoff choice. I only mentioned Layershell because you use Wayland and it's the most thorough solution. I'm not sure if X11 has anything directly comparable, but I wouldn't be surprised if it does.

We could set a "window stays on top" hint on Wayland and X11, but it doesn't actually guarantee that the window always stays on top. For instance, other apps with "window stays on top" can still appear over Spectacle if they're launched or made active. I'm also not sure I want to use the hint because it would make it harder to switch to other windows, creating the 1st issue I mentioned to a less severe degree.

> Wouldn't this be possible to prevent by having 2 separate threads (or processes) one of which acts like a watchdog. Then thread that created layershell might be destroyed by watchdog thread if the latter does not receive the signal.

You don't create a layershell object, you enable layershell for a window (technically "wayland surface", but not important). I guess maybe there could be a watchdog thread to watch the GUI thread. I'm not sure if it could distinguish between the GUI thread being actually frozen and the GUI being visually and interactively non-responsive.

I just don't see this issue as something that needs to be dealt with. It's the same as with any fullscreen window on X11 and Wayland, so not really a bug. Just minimize Konsole if you launch it second or don't launch it second unless you actually want to use it.

(In reply to Noah Davis from comment #5)
> (In reply to gudvinr+kde from comment #4)
> > You don't have this on X11.
> 
> No, on X11 I'd have to make the same tradeoff choice.

Now that you said that, I tried to reproduce the issue on X11 using different ways.
If I open up konsole from "sleep 3 && konsole" like I did in the reproduction example, you do have konsole popping up above Spectacle.

> Just minimize Konsole if you launch it second or don't launch it second unless you actually want to use it.

It was just a simple reproduction example. Of course I don't launch apps using delays in my daily workflow. The real case what I've been dealing with is trying to catch another wayland bug 489403.

When I open up thunderbird and hit "shift + print screen", it always pops up above Spectacle. Like, with 100% reproduction rate.
And on X11 I never had this. And while I was writing this comment, I tried to reproduce this again (on X11) and I still get thunderbird launching under spectacle.

> because it would make it harder to switch to other windows, creating the 1st issue I mentioned to a less severe degree.

Can't say for everyone of course, but for me personally there were no situations where I'd want to switch somewhere before I finish making screenshot. As a workaround, there could be a button that minimizes overlay but even that would be overkill I think.
But I am not saying that this argument is bad. It's just not what I'd think anyone needs.

> You don't create a layershell object, you enable layershell for a window

I am not well versed in wayland object naming, but I glad that you understood what I mean in spite of me using incorrect semantics.

> I'm not sure if it could distinguish between the GUI thread being actually frozen and the GUI being visually and interactively non-responsive.

I don't think that it matters from the user perspective tbh. You want GUI to be responsive. When it isn't, you'd likely want to kill unresponsive app anyway.

What I'm concerned about with issue 1 isn't that switching while spectacle open needs to be a viable part of someone's workflow. I'm concerned about bugs causing the UI to stop working in some way. Imagine a user who doesn't know about pressing Ctrl+Alt+F2 to switch to TTY2 and using the command line to run `killall spectacle`. If they couldn't switch windows, they'd probably think they have to restart their computer. That could cause them to lose significant amounts of time or even data, depending on what they were doing.

You could argue that a developer should never allow bugs to make it to the user, but I am not a perfect developer and Spectacle depends on other projects for core functionality. Those other projects could and often do have bugs that affect Spectacle users.

What I was getting at with the watch dog issue is that I'm concerned that the GUI could get into a situation where the thread might not technically be frozen in a way that the watchdog could detect, only visually and interactively non-functional, like a blank window would be except the window might not be visually blank.

> When I open up thunderbird and hit "shift + print screen", it always pops up above Spectacle. Like, with 100% reproduction rate.
> And on X11 I never had this. And while I was writing this comment, I tried to reproduce this again (on X11) and I still get thunderbird launching under spectacle.

I can't tell you why this happens. It could just be a timing issue due to differences in how the app works on wayland.

(In reply to Noah Davis from comment #7)
> I'm concerned about bugs causing the UI to stop working in some way. Imagine a user who doesn't know about pressing Ctrl+Alt+F2 to switch to TTY2 and using the command line to run `killall spectacle`. If they couldn't switch windows, they'd probably think they have to restart their computer.

Valid point.

> You could argue that a developer should never allow bugs to make it to the user

I wouldn't do that. Between hanging irrecoverably and having windows to pop up over spectacle I'd take the latter.
But I'd still want to happen it less often.

Maybe it is possible to push spectacle window launch at the end of launch queue if something like this exist.
Like, when you open an app and then hit print screen, you always get this app create windows first and only then spectacle creates its window.

This won't solve the issue when you create windows after spectacle already open but on X11 this issue also exist so doesn't really matter.