Created attachment 183491 [details] A Screencast That Depicts This SUMMARY When I reorder and/or merge QDockWidgets in Konsole and Dolphin, the window immediately becomes uninteractible with via my cursor thereafter, until the window has been reinitialised. This has been so since a few months ago, at least. STEPS TO REPRODUCE 1. Invoke Dolphin or Konsole. 1. Move a QDockWidget from one side of the window to another, place it atop another, or hide another with it, so that they tab. OBSERVED RESULT I become thereafter unable to interact with the window via my cursor, but can via my keyboard. EXPECTED RESULT I should remain able to interact with the window. SOFTWARE/OS VERSIONS > ~~~ > Operating System: Fedora Linux 42 > KDE Plasma Version: 6.4.3 > KDE Frameworks Version: 6.16.0 > Qt Version: 6.9.1 > Kernel Version: 6.15.7-200.fc42.x86_64 (64-bit) > Graphics Platform: Wayland > Graphics Processor 1: AMD Radeon RX 5700 > Graphics Processor 2: AMD Radeon Graphics > ~~~ ADDITIONAL INFORMATION Might be vaguely related to https://bugzilla.redhat.com/show_bug.cgi?id=2366483#c5. Ascertained whilst authoring https://invent.kde.org/frameworks/kirigami/-/issues/81#note_1267782.
> 1. Invoke Dolphin or Konsole. > > 1. Move a QDockWidget from one side of the window to another, place it atop another, or hide another with it, so that they tab. Should be 1, then 2. I'm so used to CommonMark, I occasionally forget. Apologies.
(In reply to Roke Julian Lockhart Beedell from comment #0) I've since ascertained that I remain able to move the QDockWidgets, so am merely unable to interact with all *else*.
Additionally, I've reproduced on different hardware (albeit the same OS): > ~~~ > Operating System: Fedora Linux 42 > KDE Plasma Version: 6.4.3 > KDE Frameworks Version: 6.16.0 > Qt Version: 6.9.1 > Kernel Version: 6.15.6-200.fc42.x86_64 (64-bit) > Graphics Platform: Wayland > Processors: 16 × AMD Ryzen 7 7840HS w/ Radeon 780M Graphics > Memory: 32 GiB of RAM (30.6 GiB usable) > Graphics Processor: AMD Radeon 780M Graphics > Manufacturer: Framework > Product Name: Laptop 16 (AMD Ryzen 7040 Series) > System Version: A7 > ~~~ For comparison, the original report was on: > ~~~ > Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor > Memory: 32 GiB of RAM (30.4 GiB usable) > Manufacturer: ASRock > Product Name: X670E Taichi > ~~~ Maybe mark this as spam or whatever if it's uselessly tangential.
In the screen recording - in Dolphin, dragged the Information panel from the left panel to the right panel, then back to the left panel The window elements then stopped responding to clicks Moving to kwin, which is responsible for windows
Does this happen 100% of the time when you try it? I tried a bunch of time sand couldn't trigger it. If you could send me the output of running WAYLAND_DEBUG=1 dolphin when this happens that could be helpful. It's probably very noisy so try to keep it to just reproducing the issue, thanks!
Created attachment 183605 [details] Reproduction Logs In Dolphin On Desktop (In reply to David Redondo from comment #5) Reproduced it about 5 times on my desktop. Logs are in the attached file. Note that this desktop installation is also afflicted with https://bugs.kde.org/show_bug.cgi?id=496876#c0, so if the logs on my laptop would have less false positives, I can provide that instead.
(In reply to David Redondo from comment #5) > Does this happen 100% of the time when you try it? Yes, it reproduces 100% of the time, on both laptop and desktop.
Thank you. From that it seems that KWin correctly sends button events still at the end, whcih means the issue is client side - either in Qt or Dolphin.
Created attachment 183629 [details] A Screencast That Demonstrates That The Breeze QStyle Is At Fault (In reply to David Redondo from comment #8) It can't be in Dolphin, since it affects Konsole too. Additionally, I realised today that it's probably not in KDE Frameworks, since it affects `qt6-designer-6.9.1-1.fc42.x86_64`. I considered whether KWin might be the cause at first, but you've ruled that out. That appears to leave solely the Breeze QStyle and Qt itself. I never expected it to be the cause, but the QStyle does appear to be: when I switch to Fusion via `kcm_style`, I am able to move them as much as I want. The moment I switch back to Breeze, the previously interactible application becomes unresponsive. https://youtu.be/wHrAXUVpUEA demonstrates, although I've also attached a compressed, H265 MPEG-4.
Thank you that's good investigation.
Notes from the video: 1. Dolphin, Terminal, Qt Widgets Designer, Application Style kcm open Dolphin panes - Folders and Places on left, Information on right Breeze app style is in use 2. Window elements in Dolphin and Qt Designer are highlighted under the mouse as it moves around as expected 3. Switched to Fusion app style 4. In QtWD moved the Widget Box from left to right, back to left, menus worked normally 5. In Dolphin, moved Folders from left to right, menus work normally. Moved Folders to the left 6. Same behavior in Konsole Changed App Style to Breeze In Konsole 1. Menus work normally 2. Moved Quick Commands from left to right, menus do not respond to mouse hover / click 3. Moved Quick Commands back to the left menus still ignore the mouseappli This can be replicated In Dolphin and Qt Widget Designer
Following the above steps, I cannot replicate the same exact behavior with Plasma 6.4.3, Solus and Fedora 42 I do see, however, a slightly different behavior problem with different parts of the window not interacting correctly when switching the Global Theme or just the Application Style 1. Dolphin,Application Style kcm open Dolphin panes - Folders and Places on left, Information on right Breeze Dark global theme, Breeze app style is in use 2. Once I move the Information panel in Dolphin to the left, I can't move it to the right again. I can still interact with the other window elements, unlike in the recording. Restarting plasmashell and rebooting does not change this 3. Change Application Style to Fusion - no change, even after reboot 4. Change Global Theme to Layan - no change, even after reboot Using the same steps in git-master, I can't reproduce the original bug or the other one above Step 2 - info pane can be moved multiple times, menus work properly 3. Works OK 4. Works OK Then 5. Change Application Style to Breeze - works OK So it's possible that the underlying problem is fixed in git-master Roke, do you have a system / VM with Neon Testing or another distro that runs on git-master that you can try to reproduce this on?
Created attachment 183643 [details] Reproduction In A New `neon-user-20250727-0745.iso` VM (In reply to TraceyC from comment #12) > Roke, do you have a system / VM with Neon Testing or another distro that runs on > git-master that you can try to reproduce this on? With a completely new Neon *Stable* libvirt VM, it reproduces (Unstable didn't work, per https://bugs.kde.org/show_bug.cgi?id=507644#c0). Its environment is: > ~~~YAML > Operating System: KDE neon User Edition > KDE Plasma Version: 6.4.3 > KDE Frameworks Version: 6.16.0 > Qt Version: 6.9.1 > Kernel Version: 6.14.0-24-generic (64-bit) > Graphics Platform: Wayland > Processors: 6 × AMD Ryzen 5 7600X 6-Core Processor > Memory: 15.8 GiB of RAM (15.4 GiB usable) > Graphics Processor: llvmpipe > Manufacturer: QEMU > Product Name: Standard PC (Q35 + ICH9, 2009) > System Version: pc-q35-9.2 > ~~~
(In reply to Roke Julian Lockhart Beedell from comment #13) > With a completely new Neon *Stable* libvirt VM, it reproduces Thanks. I was hoping for a test with a system that has git-master. I'll have to rebuild my Neon Testing VM, that broke itself.
I downgraded my breeze to 6.4 and can't reproduce, I also couldnt spot any relevant commits in breeze between 6.4 and master. Very curious
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
(In reply to Bug Janitor Service from comment #16) I think this was for an already-answered question (https://bugs.kde.org/show_bug.cgi?id=507446#c12), so I'm changing it back to REPORTED. However, I believe it should be CONFIRMED by now.
(In reply to Roke Julian Lockhart Beedell from comment #17) > I think this was for an already-answered question > (https://bugs.kde.org/show_bug.cgi?id=507446#c12), so I'm changing it back > to REPORTED. However, I believe it should be CONFIRMED by now. In that comment, I had asked for a test from Neon Testing, so the question had not yet been answered. CONFIRMED would not be appropriate yet, until someone else can reproduce this. See https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging#Reproduce_the_bug I've now got a working Neon Testing VM. My results were the same as my attempt on Fedora, where I couldn't reproduce this bug specifically. On git-master, the results are also the same. https://bugs.kde.org/show_bug.cgi?id=507446#c12 I'll leave this as REPORTED since we're not waiting on information.
(In reply to TraceyC from comment #18) Jan Grulich, a RedHat employee, reproduced it at https://bugzilla.redhat.com/show_bug.cgi?id=2366483#c5.
(In reply to Roke Julian Lockhart Beedell from comment #19) Sorry, wrong report. That's why I'd become confused. Apologies.