Created attachment 164192 [details] Video demonstrating the bug. SUMMARY Sometimes, seemingly randomly, I'm unable to click/interact with applications, upon clicking on them, it interacts with the desktop, and will activate any widgets I click on if they're present. Additionally, right clicking brings up the context items for the desktop. I can still interact with the program with the keyboard. I've had this happen with OBS, WebStorm (Java/IntelliJ), and Discord, so it doesn't appear to be a problem with the application itself. As I have no idea the cause, I'm unable to provide reproduction instructions, I'm happy to provide any logs, however I see nothing out of the ordinary in the journal. A video has been attached demonstrating the bug. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.6.7 Plasma 6 Beta 1 KDE Plasma Version: 5.90.0 KDE Frameworks Version: 5.246.0 Qt Version: 6.6.1
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. ***
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. ***
Just confirming with Fedora 40 and 6.0.5, this was indeed resolved. Can't reproduce the issue anymore.
Is there a follow-up issue for the underlying cause, i.e. the deleted windows that shouldn't exist in the first place? Those which are presumably caused by any of the window open/close animations?
(In reply to Cristian Le from comment #95) > Just confirming with Fedora 40 and 6.0.5, this was indeed resolved. Can't > reproduce the issue anymore. Unfortunately the issue is still alive on my side. I was so happy to see the 6.0.5 update appear, this issue is killing me, but unfortunately updating did not help. Details from system info: Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 Kernel Version: 6.5.0-35-generic (64-bit) Graphics Platform: Wayland Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz Memory: 62,5 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics Manufacturer: Dell Inc. Product Name: Latitude 5520 It's a KDE 6 fresh install (not a 5 -> 6 upgrade). Am I allowed to change the status of this report or should I create another one? I'm new here.
krobale@o-0.pl if you are able to reproduce with one of the reproducers in this thread, than I think it's worth checking it again. Otherwise it could be something more specific like in the case of firefox.
Note that on Neon, kwin is still on 6.0.4
(In reply to Nicolas from comment #99) > Note that on Neon, kwin is still on 6.0.4 Oh, I thought if `KDE Plasma Version` in the system info is 6.0.5, then all Plasma stuff, including kwin should also be on 6.0.5, if that's not the case then ok, sorry for any confusion. Is there a place with a schedule, when it's expected to be released within KDE Neon? Initially I thought KDE Neon gets stuff as soon as they are released, I was looking at this schedule: https://community.kde.org/Schedules/Plasma_6, but KDE Plasma Version got bumped to 6.0.5 like 3 days ago for me, now I learned that kwin is is not a part of this anyway
*** Bug 404002 has been marked as a duplicate of this bug. ***
Unfortunately I'm still experiencing this issue. I'm not sure how to reproduce it, it's definitely less common than before, but still exists. I have about 3-4 Rider and 1 DataGrip windows open and I get it usually once or twice a day. I'm on Fedora 40, KDE/Kwin is 6.0.5.
I have disabled the the Window Open/Close animations, I'll report back if it solves the problem in 1-2 days, maybe that helps to narrow down the issue.
Looks like it fixes the problem... I was using the scale open/close animation before, now that it's disabled I didn't get the issue again.
When using OBS with a Pipewire or xComposite source set to a specific game window, you will likely encounter an issue where the game loses focus when you click on it. This causes the game to stop rendering frames, which has been quite frustrating for me recently. When you open the start menu or do anything to take focus away from the game it will then render the frames. Any sort of screencasting will trigger this behavior by the way.
Also I'm not sure if this is a separate issue, or just a weird thing that I'm encountering. But I've noticed that when I'm using a different application, such as Firefox and I'm typing, it'll randomly do something in IntelliJ (such as bringing up a dialog.) This has only happened a few times the past few days (haven't used IntelliJ in a while) so it's not a big deal but I thought I'd bring it up. It could be some weird Xwayland thing and completely unrelated, or something I'm doing to trigger it and it's a non-issue, I'm not sure.
(In reply to Troplo from comment #106) > Also I'm not sure if this is a separate issue, or just a weird thing that > I'm encountering. But I've noticed that when I'm using a different > application, such as Firefox and I'm typing, it'll randomly do something in > IntelliJ (such as bringing up a dialog.) This has only happened a few times > the past few days (haven't used IntelliJ in a while) so it's not a big deal > but I thought I'd bring it up. > > It could be some weird Xwayland thing and completely unrelated, or something > I'm doing to trigger it and it's a non-issue, I'm not sure. That sounds like bug 490057