Bug 478556

Unfortunately the video seems to be corrupt. However based on the description, I think it might be the same issue as Bug 479926 which was just fixed today. If you're using a top or left screen edge floating panel, and if the issue only happens on *part* of the Task Manager icons, then it's the same thing.

Can you confirm that, or else upload a new video?

I don't think it's the same issue since I have floating panels disabled and it effects the entire window as you'll see in the video, the video plays just fine for me, I've uploaded it here as a mirror though, https://i.troplo.com/i/30edc9d44518.mp4 (maybe try refreshing if it looks like it's loading forever, or try downloading the file)

Thanks. Doesn't look like the issue I mentioned, indeed. What kind of GPU are you using?

(In reply to Nate Graham from comment #3)
> Thanks. Doesn't look like the issue I mentioned, indeed. What kind of GPU
> are you using?

NVIDIA RTX 2070 with the latest proprietary drivers on Arch Linux

Thanks.

Does this still happen? If yes, can you check if it's still reproducible when toggling compositing. Also could you provide the output of `xwininfo -root -tree` command and a screenshot of the monitor when you ran that command?

Created attachment 166036 [details]
Requested xwininfo output

Created attachment 166037 [details]
Requested screenshot for xwininfo output

(In reply to Vlad Zahorodnii from comment #6)
> Does this still happen? If yes, can you check if it's still reproducible
> when toggling compositing. Also could you provide the output of `xwininfo
> -root -tree` command and a screenshot of the monitor when you ran that
> command?

I recently switched to an AMD GPU (still using X11), so I don't think it's NVIDIA specific, although strangely, I know in the original report I mentioned it happened with multiple applications, I assume the other applications breaking is a side effect of IntelliJ (WebStorm), since I just had it re-occur while using WebStorm which I haven't used in a while and it hasn't happened since I last used it.

Toggling the compositor does actually fix it, not sure why I didn't think to try that a few months ago. I've attached the xwininfo output, and a screenshot to the original issue. Please let me know if there's anything else I can provide.

Side note, the xwininfo command was executed after toggling the compositor which fixed the problem.

I'm running Plasma 6 on Wayland and have the exact same problem with all IntelliJ IDEs. The problem happens whenever I have an XWayland application behind the IDE. My current “workaround” is to bring a native Wayland window to the foreground before switching to the IDE so I never have an XWayland application below it.

To illustrate it better (I hope bugzilla does not break the formatting), imagine that I opened Dolphin maximized, then opened IntelliJ IDEA:

> |----  Dolphin ----|
> |  |---- IntelliJ ----|
> |  |                  |
> |  |                  |
> |--|                  |
>    |------------------|

IntelliJ is on top of Dolphin, so this problem never happens. Also, if there's nothing behind it (i.e. only the desktop) the problem doesn't happen as well.

Now if I open Steam, which is runs on XWayland, It will go on top of IntelliJ:

> |----  Dolphin ----|
> |  |---- IntelliJ ----|
> |  |  |----   Steam  ----|
> |  |  |                  |
> |--|  |                  |
>    |--|                  |
>       |------------------|

Anything that I type on Steam gets captured by the Steam window as expected, but if I bring IntelliJ to the front:

> |----  Dolphin ----|
> |  |----   Steam  ----|
> |  |  |---- IntelliJ ----|
> |  |  |                  |
> |--|  |                  |
>    |--|                  |
>       |------------------|

The *Icons-only Task Manager* shows that IntelliJ is focused, but anything that I type or click on IntelliJ,
gets sent to Steam instead (which is very awkward). The same happens with applications like Slack that also runs on XWayland:
I type on IntelliJ, but the keys go to Slack instead.

I notice this problem very often because it's not uncommon for me to have IntelliJ, RustRover, PyCharm and WebStorm
all running at the same time, and I very often find myself trying to type on IntelliJ only to find out that all
the keystrokes went to PyCharm (despite the Task Manager showing that IntelliJ is focused).

Reproducing this problem is very tricky, there are days that I start and finish my job without it ever happening,
but once it starts happening, not even closing all IDEA instances and opening again fixes it. The only workaround is to either
minimize all windows and only have the desktop behind the IDE, or to have a native Wayland application behind the IDE,
like Firefox for example:

> |----  Dolphin ----|
> |  |----   Steam  ----|
> |  |  |----  Firefox ----|
> |  |  |  |---- IntelliJ ----|
> |  |  |  |                  |
> |--|  |  |                  |
>    |--|  |                  |
>       |--|                  |
>          |------------------|

This is something that never happened on Plasma 5 (at least for me), but TBF, it's only happening with IntelliJ, no other
X11 application running under XWayland suffers from this, and Java applications have always been problematic under XWayland.

One small problem I noticed was that when I launched Steam, IntelliJ was forcefully brought to the foreground and RustRover got highlighted
in the Task Manager (as if it requested focus). This was the first time that something stole the focus forcefully even
with the “Focus Stealing Prevention” set to “High”. 

Note that I don't think “Focus Stealing Prevention” has anything to do with the problem as I only changed this setting
a couple of days ago, but I've been experiencing this “input being sent to the wrong window” since the official release
of Plasma 6 (only with IntelliJ tho).

System:

> Operating System: Arch Linux 
> KDE Plasma Version: 6.0.2
> KDE Frameworks Version: 6.0.0
> Qt Version: 6.6.2
> Kernel Version: 6.8.1-arch1-1 (64-bit)
> Graphics Platform: Wayland
> Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
> Memory: 62,7 GiB of RAM
> Graphics Processor: AMD Radeon RX 6800

*** Bug 483270 has been marked as a duplicate of this bug. ***

*** Bug 484932 has been marked as a duplicate of this bug. ***

*** Bug 484932 has been marked as a duplicate of this bug. ***

This is possibly the same bug as bug #483998, bug #483532, and/or bug #483162

I'm not 100% sure so I didn't go and dup all of them.

I've noticed that the issue is a bit more granular in its behavior, e.g.: between IntelliJ and Element, initially the clicks are going to Element in the background, but after I activate IntelliJ, the focus is fixed. This is not the case between multiple IntelliJ windows where the focus continues to be on the background window.

*** Bug 483998 has been marked as a duplicate of this bug. ***

*** Bug 483532 has been marked as a duplicate of this bug. ***

*** Bug 485346 has been marked as a duplicate of this bug. ***

I have that happen quite a lot. I also can't find a way to fix the IntelliJ window, besides moving it to my left-most monitor, so I assume there might be some scaling included.

My setup: 100% scaled 1280x1024 on the left, 125% scaled 3440x1440 on the right. The right one is the main monitor.
I typically have IntelliJ in the left-half-quick-tile block of the big monitor.
I also have multiple virtual desktops I switch between.

Switching focus a few times between different windows, it can happen that IntelliJ can't focus anymore. Mouse-over and click events seem to "fall through" to the window below. Moving the window to the other monitor fixes it in the meantime. Moving it back sometimes works for a while and then fails again. I haven't had it fail on the left-most monitor yet. As long as the window was there, all was fine.

Now I have it happen to an open Goland instance. Moving it to my left monitor it works, moving it back to the main monitor and it's immediately "broken" again. I can Meta+Left-Click to move and Meta+Right-Click to resize, but otherwise the mouse only interacts with the window "below". Keyboard input is forwarded (i.e. I can navigate using the keyboard and also type stuff), though, as long as the window has focus.

And another addition/observation (hoping that this helps narrowing down where the problem could come from): I now closed a few other windows (especially those on the left monitor) and suddenly Goland takes mouse inputs again - even on the main screen.

Created attachment 168426 [details]
Wayland window layer bug

This is another video showing how interacting with the window on top, affects the window beneath

Comment on attachment 168426 [details]
Wayland window layer bug

>

Comment on attachment 168426 [details]
Wayland window layer bug

> ftypisomisomiso2avc1mp41moovlmvhdè!V@ötrak\tkhd!H@T$edtselst!Hnmdia mdhd2ªUÄ-

Will you please delete that clip, it was a wrong one I uploaded.


On 12/04/2024 21.20, Oded Arbel wrote:
> https://bugs.kde.org/show_bug.cgi?id=478556
>
> Oded Arbel <oded@geek.co.il> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>   Attachment #168426 [details]|1                           |0
>             is patch|                            |
>   Attachment #168426 [details]|text/plain                  |video/mp4
>            mime type|                            |
>

Comment on attachment 168426 [details]
Wayland window layer bug

I don't have access to delete attachments from tickets. I'm not sure it is possible.

Sysadmins can. I've contacted them about it.

The content of attachment 168426 [details] has been deleted for the following reason:

requested by user

Same issue here since updated to Plasma 6. Randomly the mouse click (left and right, it doesn't matter) goes through top level window (from the z order perspective) and generates the corresponding click events on the window beneath it, so instead of focusing the desired top level window the focus is given to the window beneath it (or desktop, if no lower level window present). It is really frustrating because you cannot interact at all with the window. Changing *any* option in System Settings -> Window Management -> Window Behavior and click Apply would temporary fix the issue (for example change "Delay focus by" from default 300 ms to anything else and click Apply (the same with any option etc.). After a certain time interval (minutes, tens of minutes) or may some event (I didn't investigate for the moment), the problem manifests itself again.

It happens on both X11 and Wayland.
I'm using nvidia driver (470.239.06) on a GeForce GTX 765M graphics card.
I tried to test on nouveau but there are so many issues with nouveau (from freezing to segfaults etc.) that I couldn't use it at all.

I will get back with more information if / when I get more time to investigate it.
Thank you.

*** Bug 483162 has been marked as a duplicate of this bug. ***

*** Bug 484218 has been marked as a duplicate of this bug. ***

I noticed the Version field is 5.90.0 for this bug, but it is affecting all 6.x versions (currently I'm on 6.0.3.1 for example).
It never happened for 5.x versions (not considering 5.90.x versions), basically this problem started only after updating to 6.x.

To avoid having this bug fix postponed due to triage criteria (based on Version field), is it possible please to adjust the Version field accordingly?

Thank you.

One more thing, the title mentions "Xorg", but in reality it happens on both X and Wayland with the same occurrence probability.

Thank you.

## Summary

It may be worth summarizing what we know so far:
- No linked MR thus far
- Affected KDE: Current Plasma 6, but also traceable to 5.90
- Easily replicable, but must be between select window types. To replicate, alt+tab to switch focus between offending windows
  (IntelliJ is commonly reported so alt+tab between CLion and Pycharm windows that are overlapping) 
- Affects native X11 and XWayland windows. No report between X windows and native wayland or between wayland windows thus far
- Not related to graphics card, HighDPI scaling etc.
- Focus Stealing Prevention etc. does not affect it
- Meta + Left/Right Click affects the **correct** window

## Requested debug info

Nothing new requested.

`xwininfo -root -tree` was requested at some point and provided. If still needed, I can provide a video of `watch` and replicating the bug if there is some guidance on how to filter the relevant windows.

## Discussed fixes

### Toggle compositor (Alt+Shift+F12)

This does not seem to have any effect, navigating the dbus interface (/org.kde.kwin.Compositing.active is always True). Does not affect the bug's reproducibility. (I.e. even if I do use Alt+Shift+F12 I am still replicating the issue)

### Changing any option in System Settings -> Window Management -> Window Behavior

Does not affect the bug's reproducibility. Still replicable on my side with the alt+tab.

---

That's all I have so far

(it's unfortunate with bugzilla we can't edit comments, otherwise it would be nice to keep top most comment up-to-date with the current status, will try to summarize every now and then)

Is any KDE dev looking into this or actually tried to reproduce it?
(Don't know who's who here)

Regarding the summary written, I am not saying that this is not looked by KDE-devs, I am sure this is major bug that is being looked into given how prevalent it is and how many duplicate issues are being triaged. Nate seems also quite concerned about this bug?

It's just that we (KDE users) haven't been updated on where to follow the work for this bug, and we weren't asked for more debug information in a while.

(In reply to Cristian Le from comment #37)
> It's just that we (KDE users) haven't been updated on where to follow the
> work for this bug, and we weren't asked for more debug information in a
> while.
I don't expect to be able to follow their work, but I haven't seen any requests for further info or some indication it's actively being looked into right now (or maybe I missed it) - hence my question.

There are other regressions/bugs coming from 5.2x that I have encountered but this is the most annoying one, to the point it's making me consider switching DEs.

I am hitting what seems to be the same bug lately.

NVIDIA GTX 970M, proprietary drivers
X11
Plasma 6 from git

Is it consistent? No.
How to reproduce it? I have no idea so far.

I was given some ideas how to debug it using KWin support information, so I'll do that next time(s) it happens:

$ qdbus org.kde.KWin /KWin supportInformation
$ xprop -root

FWIW I'm a KDE dev, although not much in KWin area. Let me assure you, we want this bug fixed, however it is hard to do so without reliable steps to reproduce it, and it seems to be quite random so far.

Thanks for lettings us now you are on it!
I'll try those commands the next time it happens and upload.

Created attachment 168608 [details]
qdbus org.kde.KWin /KWin supportInformation

Output of the command 'qdbus org.kde.KWin /KWin supportInformation' while the bug is happening.

Created attachment 168609 [details]
xprop -root

Output of the command 'xprop -root' while the bug is happening.

Well it just happened again as soon as I switched back to WebStorm, maximized and then unmaximized the window.
I have attached files of the output of the two commands.

Created attachment 168610 [details]
supportInformation (XWayland)

Created attachment 168611 [details]
xprop -root (XWayland)

(In reply to ratijas from comment #39)
> Is it consistent? No.
> How to reproduce it? I have no idea so far.

I don't suppose you have the IntelliJ IDEs do you? I have 99% reproducibility with them just because there are 2 equivalent apps with multiple windows, it is very easy to reproduce (and encounter randomly). My reproduction steps:

1. Open 2 IDEs with multiple windows
2. Move focus away from all windows, e.g. go to Firefox and let everything "settle"
3. Go into one of the IDE windows
4. Alt+tab to another window (often can be within the same IDE) and try to interact with the window that became focused
5. Commands are forwarded to background app, move the windows, minimize etc. to actually bring the "foreground" app into "full" focus

My understanding is that the files there give you mostly static info (mine are equivalent other than X11->XWayland), but are there anyway to give some debug info about the active focus changes? Maybe some `qbus` listeners or a `watch` command that we can record the full process?

The output of "xwininfo -root -all" could be useful. But you need to check it for personal information, it contains Window titles.

By the way, there's an issue at the Jetbrains issue tracker, too: https://youtrack.jetbrains.com/issue/JBR-6921

And "xev -root", at least on X11.

Created attachment 168615 [details]
xwininfo (XWayland)

Here is my `xwininfo`. One thing I notice is that it has `FocusProxy` on the content windows. I don't have a reproducible flow for non-IntelliJ windows that I could check if this is the case for those as well

(In reply to Cristian Le from comment #35)
> ## Summary

Hello Cristian,

good summary, thank you.

I would like to add that I disabled the compositor today (System Settings -> Compositor -> Enable on startup [unchecked] -> restart KWin / reboot) and I didn't encountered the issue anymore (I was constantly and continuously using 3 Rider instances + 1 CLion instance for about 11 hours). I really don't know why I didn't try that sooner.

Thanks.

A workaround I found to be able to not get too annoyed with this bug is to click on the "minimize window" until the actual window being displayed matches the "real" window with focus.

Quick comment, changing compositor option does not seem possible on KDE6? Or at least not on the F40 beta branch


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: F40 
KDE Plasma Version: 6.0.3
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2

(In reply to Cristian Le from comment #52)
> Quick comment, changing compositor option does not seem possible on KDE6? Or
> at least not on the F40 beta branch
> 
> 
> SOFTWARE/OS VERSIONS
> Linux/KDE Plasma: F40 
> KDE Plasma Version: 6.0.3
> KDE Frameworks Version: 6.0.0
> Qt Version: 6.6.2

Are you on Wayland? Disabling/toggling the compositor is only available on X11, although if you are on X11 and the option is missing, you could try ALT + SHIFT + F12 and iirc it remembers the compositor toggle state on subsequent reboots.

Indeed I am on Wayland, and at least by navigating the dbus environment it doesn't seem to have any effect. Not sure if it counts odd/even how many times I Alt+Shift+F12, but I don't think that's the case. Is the compositor an X11/XWayland specific thing?

(In reply to Cristian Le from comment #54)
> Indeed I am on Wayland, and at least by navigating the dbus environment it
> doesn't seem to have any effect. Not sure if it counts odd/even how many
> times I Alt+Shift+F12, but I don't think that's the case. Is the compositor
> an X11/XWayland specific thing?

Yeah it's X11 specific, that shortcut won't do anything on Wayland due to the Wayland server being a compositor itself

Just wanted to say this is affecting me as  well, how I fix it , is by killing kwin_x11  that seems to recover everything. Although maybe that is horrible.

> Just wanted to say this is affecting me as  well, how I fix it , is by killing kwin_x11  that seems to recover everything. Although maybe that is horrible.

Lol, just have a "Nuke X11" button on a shortcut :)). But speaking of which, it would be worth confirming for the others that would want a dirty fix in the meantime, does killing kwin_x11 restart the applications smoothly from where they were left off? I remember this being a major implementation for Plasma6 and Wayland.

> Lol, just have a "Nuke X11" button on a shortcut :)). But speaking of which, it would be worth confirming for the others that would want a dirty fix in the meantime, does killing kwin_x11 restart the applications smoothly from where they were left off? 

Yes sorry, to be clear when I do that, it takes about 5 seconds but my session continues without any negative side effects, the side effects are minimum. All my applications seem unaffected, no crashes or anything.

Everybody talking about workarounds instead of asking the relevant question: are the devs able to "reliably" reproduce the bug with JetBrains' products at this point, as opposed to waiting for the bug to occur in "normal" use?

It's enough the keep any of the JetBrains IDEs open and interacting with the IDE a little while doing other work, and the bug will inevitably appear, several times a day.

I can confirm switching between X11 and Wayland session has no effect for me regarding this bug, I get it many times a day either way. Jetbrains IDEs run in XWayland anyway. I have bound "killall kwin_x11" to Meta+F1 for now, horrible or not, if it works it's not stupid :)

*** Bug 486058 has been marked as a duplicate of this bug. ***

I've found quite fast repro, it's still random, but breaks by 2-15 slow clicks (after `reboot` or `killall kwin_x11`):

https://youtu.be/zjreuC6gPDQ

3 IntelliJ IDEA + 1 Kitty + 1 Chrome
Note: for me it breaks ONLY with IDEA, i've tried DBeaver and OBS - no such problem.
Hope it may help.

(In reply to vm from comment #62)
> I've found quite fast repro, it's still random, but breaks by 2-15 slow
> clicks (after `reboot` or `killall kwin_x11`):
> 
> https://youtu.be/zjreuC6gPDQ
> 
> 3 IntelliJ IDEA + 1 Kitty + 1 Chrome
> Note: for me it breaks ONLY with IDEA, i've tried DBeaver and OBS - no such
> problem.
> Hope it may help.


If you want something that is mit random. Try Apex Legends. It ses to trigger it exactly the same, always in an instant

The bug in the JetBrains youtrack: https://youtrack.jetbrains.com/issue/PY-72228/Input-events-are-passed-to-underlying-X11-window

Unfortunately, that bug will probably be resolved as duplicate of https://youtrack.jetbrains.com/issue/JBR-6921, which is already resolved as third-party problem.

I reproduced the issue using the method demonstrated by Vm in his video above. It works well, but took more clicks for me. I also tried two other applications instead of IntelliJ: a Java Swing app and a Compose Desktop app, both using the default JRE and and Jetbrains' JRE (found in ~/.jbr/). It didn't happen with them.

Unfortunately, I did not found that bug report before reporting mine.

But for that developer who will go fixing this, I want to make a note, that it is worth checking Comment #64 link, because I have extensively described there two other reproduce methods and attached a video.

Thank you Sebastian for the link, so far the "experimental" fix in https://youtrack.jetbrains.com/issue/JBR-6921/Plasma-6-Cannot-click-on-one-IDE-instance-when-a-second-one-is-running#focus=Comments-27-9734185.0-0 seems to be working for me. It even fixes the High-DPI scaling issue :)

Another way to reproduce this bug is to run FastTracker II Clone (ft2-clone). As soon it runs I lose ability to interact with anything except for the desktop.

This is not an IDEA issue because it has no effect before plasma6.
And this makes plasma6 completely unusable for developers that uses IDEA-based IDE.
So it has to have a highest prioirty.

As a crutch idea, I think one could make a kwin script that switches the virtual desktop forward and backward at any time the jetbrains window (or any x11 window? but experienced most with jetbrains) is moved, resised, activated.

(In reply to NoPH8 from comment #69)
> This is not an IDEA issue because it has no effect before plasma6.
> And this makes plasma6 completely unusable for developers that uses
> IDEA-based IDE.
> So it has to have a highest prioirty.

One winning strategy here is to just live with this bug long enough that Jetbrains finish their Wayland support :-)

(In reply to Ondřej Hruška from comment #71)
> 
> One winning strategy here is to just live with this bug long enough that
> Jetbrains finish their Wayland support :-)

The joke is funny, the situation is sad =(

It's look like I'll switch to Mac before.

After a lot of debugging i think i've found at least a better workaround.

Workaround: 

Quite simple - disable ALL effects in "Window Open/Close Animation" group.

Details:

It looks like when any of these effect are enabled KWin starts leaking Window instances, as they sometimes not getting deleted. 

In IDEA every button (such as Run/Debug, Settings, left panel buttons) - has a tooltip.
When you hover over any of these IDEA button it creates new X window to display a tooltip. 
When mouse leaves that button - tooltip window is destroyed.
KWin tries to animate destruction of that tooltip (...yeah tooltip death animation...)
And sometimes it causes that Window instances (previously used by tooltips) are never be deleted (a lot of X11Window instances holding m_client = 0x0), because m_refCount counter never reaches zero.
Why and where it leaks exactly i'm still don't understand, but the problem somewhere in this effects implementation.
A few moments later this leaked Window instances start causing a lot of stacking issues.

Look:

https://youtu.be/1jiKEP-MJQQ

What i've done - added simple logging to Workspace::updateStackingOrder (and some quite simple helpers - such as refCount() to Window.h for debugging reasons):

    void Workspace::updateStackingOrder(bool propagate_new_windows)
    {
        if (m_blockStackingUpdates > 0) {
            if (propagate_new_windows) {
                m_blockedPropagatingNewWindows = true;
            }
            return;
        }
        QList<Window *> new_stacking_order = constrainedStackingOrder();
        bool changed = (force_restacking || new_stacking_order != stacking_order);
        force_restacking = false;
        stacking_order = new_stacking_order;
        if (changed || propagate_new_windows) {
            propagateWindows(propagate_new_windows);

            for (int i = 0; i < stacking_order.size(); ++i) {
                stacking_order[i]->setStackingOrder(i);
            }

            Workspace::debugStacking("Stacking order changed!!!", stacking_order); // <----------------------------------

            Q_EMIT stackingOrderChanged();

            if (m_activeWindow) {
                m_activeWindow->updateMouseGrab();
            }
        }
    }

    void Workspace::debugStacking(const char* prefix, const QList<Window*>& stacking) {
        QString debugString;
        for (Window* w: stacking) {
            X11Window* x11w = static_cast<X11Window*>(w);
            debugString.append(QString("  instance = 0x%1 refCount = %2 window = 0x%3 desc = %4\n")
                .arg(reinterpret_cast<uintptr_t>(x11w), 0, 16)
                .arg(x11w->refCount())
                .arg(x11w->window(), 0, 16)
                .arg(x11w->windowDesc()));
        }
        qDebug("%s!!!\n%s", prefix, qUtf8Printable(debugString));
    }

Also i've launched gdb to get backtraces with this commands:

    gdb ./kwin_x11
    
    break window.cpp:113
    commands
    silent
    bt 6
    continue
    end

    break window.cpp:118
    commands
    silent
    bt 6
    continue
    end

    run --replace`

But without success as i didn't find a real reason - looks like Window references are hold by EffectWindowDeletedRef, but why... 

With all this in mind:

What i clearly know - KWin Window leaking - doesn't look like IDEA problem. 
I think this is also reproducible with ANY software which can create/delete windows as fast as IDEA does.

@vm Thanks for sharing!
And wow, I did not know that you can click on radio button to disable that. Very counter-intuitive... It should be a radio-button with the check mark ("V") inside, instead of circle, to indicate that you can disable it as a checkbox.

Thanks, vm, for keeping digging and figuring this out!

Created attachment 169076 [details]
screencast showing a window that is only partially “transparent” for mouse events

I am affected too, and there is a detail that I have not seen in the discussion yet: I managed to end up in a situation where only a fraction of the affected window is “transparent” for mouse events. If this is an already known symptom, then sorry for the noise.

The problem can be reliably reproduced with Firefox as follows:

- Right-click toolbar and choose “Customize Toolbar …”.
- Disable “Title Bar”.
- Resize the window as you like. This will define the normal behaving region.
- Enable “Title Bar”.
- Resize to a larger window.
- Now the window is “transparent” for mouse events in the area that was added by the previous resize.
- Note that the added width of the title bar is not affected.
- Disabling “Title Bar” again undoes the effect. (You might have to make the window smaller again before being able to click the check box.)

According to `qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole`, Firefox is a Wayland window

Software versions:

- Arch Linux
- KWin package version 6.0.4.1-1
- Firefox package version 125.0.3-1

I attach a screencast showing some right-clicks in the Firefox window, where some open a Firefox context-menu while others open the Plasma desktop menu.

I can 100% reproduce the behavior in comment #76 on Neon Plasma Wayland 6.0.4. Showing this issue with a non-Intellij application, especially one that is easily reproducable is awesome - great work @Flupp!

A lot of people in this ticket are talking about running on Xorg and not on Wayland, and I thought that the Wayland ticket for this behavior was bug #483162 - but that was apparently closed as a dup of this one, though I'm not convinced that the Wayland behavior and the Xorg behavior is exactly the same thing. I would be interested in seeing if any of the Xorg running folks can repro the Firefox problem described above.

A few notes about the Firefox reproduction:
- When reproing with a single window, note that when the desktop menu shows, the Firefox window becomes inactive - if there was a second window under the problematic window then it would have been raised - I don't think this happened with the Intellij repro, leading me to suspect that it is not exactly the same bug.
- With the issue presenting, you can still drag the window from the kwin decoration or resize the window from the border.
- In the region where clicks "pass through" to the underlying surface, no other mouse event will be received by the window - you can see that hover events do not activate, but also trying to use the window operations modification key (normally META) would not let you drag the window or resize it from that region.

(In reply to Oded Arbel from comment #77)
> I can 100% reproduce the behavior in comment #76 on Neon Plasma Wayland
> 6.0.4. Showing this issue with a non-Intellij application, especially one
> that is easily reproducable is awesome - great work @Flupp!
> 
> A lot of people in this ticket are talking about running on Xorg and not on
> Wayland, and I thought that the Wayland ticket for this behavior was bug
> #483162 - but that was apparently closed as a dup of this one, though I'm
> not convinced that the Wayland behavior and the Xorg behavior is exactly the
> same thing. I would be interested in seeing if any of the Xorg running folks
> can repro the Firefox problem described above.
> 
> A few notes about the Firefox reproduction:
> - When reproing with a single window, note that when the desktop menu shows,
> the Firefox window becomes inactive - if there was a second window under the
> problematic window then it would have been raised - I don't think this
> happened with the Intellij repro, leading me to suspect that it is not
> exactly the same bug.
> - With the issue presenting, you can still drag the window from the kwin
> decoration or resize the window from the border.
> - In the region where clicks "pass through" to the underlying surface, no
> other mouse event will be received by the window - you can see that hover
> events do not activate, but also trying to use the window operations
> modification key (normally META) would not let you drag the window or resize
> it from that region.

Yes, its also reproduces on Xorg. I think it the same problem.

Fantastic, I can reproduce that as well.

Firefox being click-through in some parts of the window is a Firefox bug, see https://bugzilla.mozilla.org/show_bug.cgi?id=1844497 (also happens on Wayland, or at least one with similar symptoms). It's not the same issue as described in this bug report.

(In reply to vm from comment #73)
> After a lot of debugging i think i've found at least a better workaround.
> 
> Workaround: 
> 
> Quite simple - disable ALL effects in "Window Open/Close Animation" group.
> 
> But without success as i didn't find a real reason - looks like Window
> references are hold by EffectWindowDeletedRef, but why... 

I checked the code and added some logging too, but I haven't been able to see anything that's wrong with window references so far

(In reply to vm from comment #73)
> After a lot of debugging i think i've found at least a better workaround.
> 
> Workaround: 
> 
> Quite simple - disable ALL effects in "Window Open/Close Animation" group.
> 
> Details:
> 
[...]

Thank you, I appreciate your investigation and our time spent on it.

The bug is not triggered anymore after disabling all effects in "Window Open -> Close Animation".
In my opinion it is a step forward compared to disabling the compositor altogether.

(In reply to Zamundaaa from comment #80)
> Firefox being click-through in some parts of the window is a Firefox bug,
> see https://bugzilla.mozilla.org/show_bug.cgi?id=1844497 (also happens on
> Wayland, or at least one with similar symptoms). It's not the same issue as
> described in this bug report.

According to the discussion in the Mozilla bug tracker, this is a KWin-specific issue so likely a bug in KWin (I didn't see anyone commenting that they specifically failed to reproduce this in specific non-KDE configurations, but the issue only presenting on KWin was said a few times). 

If the Firefox behavior is not this bug - then it should be reported and tracked in another KDE bug report.

(In reply to Oded Arbel from comment #82)
> According to the discussion in the Mozilla bug tracker, this is a
> KWin-specific issue so likely a bug in KWin (I didn't see anyone commenting
> that they specifically failed to reproduce this in specific non-KDE
> configurations, but the issue only presenting on KWin was said a few times). 
> 
> If the Firefox behavior is not this bug - then it should be reported and
> tracked in another KDE bug report.

No, it's a Firefox bug. On Xorg, KWin isn't involved in input routing, and on Wayland I can very easily see Firefox setting the wring input region.

(In reply to Zamundaaa from comment #83)
> No, it's a Firefox bug. On Xorg, KWin isn't involved in input routing, and
> on Wayland I can very easily see Firefox setting the wring input region.

Firefox upstream just applied a "workaround" (their definition) to fix this issue by updating the input region.

A. do we know that the issue with input region being set incorrectly by the window (and or not updated on resize) isn't what the IntelliJ issue is about?
B. IIUC, shaping the input region is related to non-rectangular windows, i.e. windows with transparent parts where the surface will not receive events on those transparent areas - isn't the Firefox issue flies in the face of Wayland security assurances? If windows can decide not to receive events on areas they paint (and let them "fall through" to the next window) it sounds like they can also grab events on areas that they don't paint by shaping their input region to be larger than the painted region - this seems problematic to me.

(In reply to Oded Arbel from comment #84)
> Firefox upstream just applied a "workaround" (their definition) to fix this
> issue by updating the input region.
Afaiu GTK is doing something wrong, so that seems fine.

> A. do we know that the issue with input region being set incorrectly by the
> window (and or not updated on resize) isn't what the IntelliJ issue is about?
I'm relatively sure that's not possible; Xwayland doesn't set any input regions (yet), so it always covers the whole window for X11 apps on Wayland.

> B. IIUC, shaping the input region is related to non-rectangular windows,
> i.e. windows with transparent parts where the surface will not receive
> events on those transparent areas - isn't the Firefox issue flies in the
> face of Wayland security assurances? If windows can decide not to receive
> events on areas they paint (and let them "fall through" to the next window)
> it sounds like they can also grab events on areas that they don't paint by
> shaping their input region to be larger than the painted region - this seems
> problematic to me.
Apps don't get input events outside of the input region. There's no grabbing input events on Wayland.

(In reply to Zamundaaa from comment #85)
> (In reply to Oded Arbel from comment #84)
> > A. do we know that the issue with input region being set incorrectly by the
> > window (and or not updated on resize) isn't what the IntelliJ issue is about?
> I'm relatively sure that's not possible; Xwayland doesn't set any input
> regions (yet), so it always covers the whole window for X11 apps on Wayland.

OK, that makes sense, I guess. I tried to reproduce the Firefox issue with XWayland (forcing Firefox to run on XWayland by starting it as `WAYLAND_DISPLAY= firefox`) and it does not reproduce.

Which begs the question - how did @vm reproduce the Firefox issue on X11, and what is going on with the Mozilla issue 1844497 that was originally reported for X11?

Created attachment 169108 [details]
Firefox input regions

Here is screenshot, pure Xorg, in firefox input regions doesn't updates when i resize frame window. 
As you can see - bounding is ok, but input is broken.
As a result - frame window input regions are broken too.
I'm not sure who is responsible for updating input regions when window is resized. 
And i don't know why rectangular windows need some mess with shapes at all... - looks strange

Today I encountered this bug again (with IDEA).
Accidentially forgot to disable animations.
But this helps me to finally spin off this history.

I wrote a fairly simple utility that calls xcb_query_tree (which guarantees to returns windows in Xorg stacking order) and xcb_shape_get_rectangles to get all the regions.
Now it's known for sure that in the case of IDEA, everything is ok with those regions (bounding, clip, input).

The problem itself is in the title of this ticket - KWin::Workspace::stacking_order != X11 stacking order. And the main hint was in title of this ticket all the time.

If you reproduce that problem and then try to Minimize and open broken window again, visually the window appears on the screen first and is drawn first, but all the input goes to the window that is at the bottom of the list from xcb_query_tree.
And i found that these broken IDEA windows appears BEHIND Desktop window according to X11 stacking order, however on top of KWin::Workspace::stacking_order.
Also some people showed here that not only IDEA windows breaks - but IDEA app must be launched. 

Now let's recheck how restacking works (on X11):

	static inline void restackWindows(const QList<xcb_window_t> &windows)
	{
	    if (windows.count() < 2) {
	        // only one window, nothing to do
	        return;
	    }
	    for (int i = 1; i < windows.count(); ++i) {
	        const uint16_t mask = XCB_CONFIG_WINDOW_SIBLING | XCB_CONFIG_WINDOW_STACK_MODE;
	        const uint32_t stackingValues[] = {
	            windows.at(i - 1),
	            XCB_STACK_MODE_BELOW};
	        xcb_configure_window(connection(), windows.at(i), mask, stackingValues);
	    }
	}

How its expected to work - we take a list of windows and for each window say - the previous window MUST BE BELOW current window.
But... As you might remember - KWin has leaking Window objects (Window objects without any bounded Xorg window to it - frameId = 0x0, wrapper = 0x0, window = 0x0, inputId = 0x0) when Open/Close animation is enabled.

And when we encounter such window - we make the next calls:

	const uint32_t stackingValues[] = {
	    0x3800045, // for example
	    XCB_STACK_MODE_BELOW
	};

	xcb_configure_window(connection(), 0x0, mask, stackingValues);

This must cause XCB error, but it's swallowed anyway...

The next call: 

	const uint32_t stackingValues[] = {
	    0x0, // <---- ...
	    XCB_STACK_MODE_BELOW
	};

	xcb_configure_window(connection(),  windows.at(i), mask, stackingValues);

And XCB do this - places window BEHIND ALL OTHER WINDOWS (behind Desktop and others). 
All next windows in this list - also placed behind Desktop window - making whole pack of windows effectively unclickable (but still visible).

So, for now the fix is deadly simple - filter out 0x0 windows from X11 xcb_window_t passed to restackWindows.

To reproduce and recheck:

1. X11
2. Enable Scale animation effect (Open/Close animation group). 
3. Build KWin with debug symbols (or use debuginfod), wire up gdb:

gdb ./kwin_x11

# to preload symbols
run 

break xcbutils.h:1965
commands
silent
printf "xcb_configure_window: 0x%x below 0x%x\n",windows.at(i-1),windows.at(i)
continue
end

4. Watch videos above about how to reproduce
5. Check output produced by gdb, something like: xcb_configure_window: 0x0 below 0x1600032

Unfortunately, i dont have access to create Merge Requests to KWin directly, so..
The next is the diff with the fix for X11 (against master branch):

diff --git a/src/layers.cpp b/src/layers.cpp
index 45baa452d6..54a5df0bd6 100644
--- a/src/layers.cpp
+++ b/src/layers.cpp
@@ -165,7 +165,7 @@ void Workspace::propagateWindows(bool propagate_new_windows)
 
     for (int i = stacking_order.size() - 1; i >= 0; --i) {
         X11Window *window = qobject_cast<X11Window *>(stacking_order.at(i));
-        if (!window || window->isUnmanaged() || window->hiddenPreview()) {
+        if (!window || !window->frameId() || window->isUnmanaged() || window->hiddenPreview()) {
             continue;
         }
 
@@ -182,7 +182,7 @@ void Workspace::propagateWindows(bool propagate_new_windows)
     // these windows that should be unmapped to interfere with other windows
     for (int i = stacking_order.size() - 1; i >= 0; --i) {
         X11Window *window = qobject_cast<X11Window *>(stacking_order.at(i));
-        if (!window || window->isUnmanaged() || !window->hiddenPreview()) {
+        if (!window || !window->frameId() || window->isUnmanaged() || !window->hiddenPreview()) {
             continue;
         }
         newWindowStack << window->frameId();

But im unsure about Wayland... Does it exist on Wayland?

As for Window leaks - i think its subject for another ticket - with much lower priority. 
But Window objects are leaking - that true.

This bug was the reason i downgraded to 5 and finally! Thank you for your time vm, you are a hero.

Great investigation! Please make a merge request and we'll get that backported for 6.0.5

> But im unsure about Wayland... Does it exist on Wayland?
I don't think the X11 stacking order should affect input event routing on Wayland, but with X11 there's often surprises. Only way to know for sure is for someone to test the patch

(In reply to Zamundaaa from comment #90)
> Please make a merge request and we'll get that backported for 6.0.5

https://invent.kde.org/plasma/kwin/-/merge_requests/5692

Git commit 4e01d2c8b7a0edf49c1b49fbaf7cbc3663592da4 by Vyacheslav Mayorov.
Committed on 03/05/2024 at 17:00.
Pushed by zamundaaa into branch 'master'.

workspace: fix syncing the stacking order with Xorg

Deleted windows have frameId zero, which makes Xorg stack other windows
below the bottom-most window instead of the correct one. To avoid that,
filter out deleted windows in Workspace::propagateWindows.

M  +2    -2    src/layers.cpp

https://invent.kde.org/plasma/kwin/-/commit/4e01d2c8b7a0edf49c1b49fbaf7cbc3663592da4

Git commit e5313626b7de7ca036ef4d273febc214a61466ef by Xaver Hugl, on behalf of Vyacheslav Mayorov.
Committed on 03/05/2024 at 17:22.
Pushed by zamundaaa into branch 'Plasma/6.0'.

workspace: fix syncing the stacking order with Xorg

Deleted windows have frameId zero, which makes Xorg stack other windows
below the bottom-most window instead of the correct one. To avoid that,
filter out deleted windows in Workspace::propagateWindows.


(cherry picked from commit 4e01d2c8b7a0edf49c1b49fbaf7cbc3663592da4)

M  +2    -2    src/layers.cpp

https://invent.kde.org/plasma/kwin/-/commit/e5313626b7de7ca036ef4d273febc214a61466ef

*** Bug 486026 has been marked as a duplicate of this bug. ***