I started to notice this after update to RC1. If I leave some windows open on an external display and disconnect it, the windows remain on their original positions instead of moving to the remaining internal display. I can right-click on the affected windows in the taskbar, select the "Move" action and drag the windows back into view. This is happening under Wayland, I didn't check under X11. Arch Linux KF6 5.248.0 Plasma 5.92.0
You say it broke in RC1; does this mean it was working in the earlier beta release?
(In reply to Nate Graham from comment #1) > You say it broke in RC1; does this mean it was working in the earlier beta > release? As far as I can tell, yes, at least I cannot recall this to happen since a very long time ago. I'm juggling my external screens quite a lot so I think I would have noticed. To be fair it isn't reliably reproducible so maybe there is something else going on...
Thanks. It would be great if you can narrow down the exact circumstances under which it happens, because I'm not able to reproduce the issue for my own multi-monitor use case of unplugging a secondary screen and using my laptop as a laptop.
Created attachment 164861 [details] Screen layout
I got it to happen again. It does not appear to be connected to (dis)connections of displays but to changes of display modes in general. I managed to trigger the issue twice by resuming the laptop from sleep, hooking the screen up, waiting for it to light up and *then* unlocking the session. In those cases, one of my windows was placed at (0,0) coordinates of the bounding rectangle of my display space. Since that's outside of what my displays show, the window was invisible (my display config is on the attached screenshot). I could tell what the window's position was by looking at the preview of window positions on the virtual desktops widget. Another time it happened when I switched the resolution of my external screen. In that case, one window got moved somewhere to the bottom right of my display space and I couldn't even see its position on the virtual desktops widget. In all cases I could eventually pull the window back into view. I have been using RC1 for about one day and this has happened about 5 or 6 times now. I'm, therefore, sure that I would have noticed this if it was happening before RC1.
Unfortunately the root cause is probably even more elusive than I had originally thought. One window got moved to (0, 0) position without any change in display configuration. The window was on a virtual desktop that I was not using when it happened so I don't know what exactly triggered it. I know I was moving some windows around to arrange them neatly for some screenshots. Additionally, when this happens, KWin seems to become confused about the display setup. This manifests by new windows opening on the wrong screen or the window snapping feature using wrong dimensions. I'm afraid that there is no easily discernible way how to trigger this but it keeps happening rather frequently
*** This bug has been marked as a duplicate of bug 379333 ***
Sorry, maybe not. The issue looks rather like the one reported in Bug 452118 which is supposed to be fixed in Plasma 6; can you reproduce the issue with the final release of Plasma 6?
I have this problem now on KDE Neon 6, and I never had the issue before moving to KDE 6 and Wayland
Can affected people mention which specific windows are affected? Is it always the same ones?
(In reply to Nate Graham from comment #10) > Can affected people mention which specific windows are affected? Is it > always the same ones? reproducing steps (on fedora 40 plasma 6.0.3, laptop with external monitor connected): 1. open System settings on external monitor (while external is set to primary) 2. uncheck "enabled" + apply 3. System settings is not moving to the available monitor, and I'm unable to use is (it's also not showing on overview) 4. the app is showing is open in the "Icons only task manager" so when minimizing and opening again, it opens on the available monitor. I tried to record it with Spectacle, but it seems to crash when disabling a monitor while recording screen
Created attachment 169851 [details] screencast of the bug happened again so this time i recorded it, this is so frustrating that when i disconnect a monitor, im unable to use some windows, i usually quit the app and re-open
*** Bug 480032 has been marked as a duplicate of this bug. ***
I'm able to reproduce this 100% with only NeoChat. When I have it on my external screen (to the right of the laptop screen), unplugging the screen makes NeoChat move to an off-screen area, and it's not accessible on the laptop screen until I minimize it and then un-minimize it; when it un-minimizes, it gets moved to the laptop screen.
I have been running into this issue quite a bit on KDE 6.1. My display setup is two 4K monitors situated side by side with an external 1080P TV situated on the top right edge when it's turned on. In certain situations, I will lock the system with Firefox maximized on the TV display. When I come back, I unlock the system which wakes everything up except for the TV containing Firefox. At this point, Firefox becomes inaccessible to me unless I do the "maximize/un-maximize" trick to force it onto one of the two surviving 4K displays. Setup: Arch Linux Plasma 6.1.0 Frameworks 6.3.0 Qt 6.7.1 Linux 6.9.5-arch1-1 Wayland AMD Ryzen 9 5950X AMD Radeon RX 6900 XT
That doesn't necessarily sound related. Is the TV still shown in the display settings? TVs usually don't disconnect just because they're in standby
*** Bug 490733 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6234
Git commit 370c9c895373838cb5d4b51ff26ad9b54f3f9ef5 by Xaver Hugl. Committed on 14/08/2024 at 11:38. Pushed by zamundaaa into branch 'master'. window: make setQuickTileMode more sane ...by removing the keyboard flag, moving keyboard shortcut handling into a separate method and making the position to tile the window at explicit This also means KWin doesn't do as many intermediary changes to window geometry on output hotplugs, which may work around some clients not always reacting to no-op changes. M +1 -1 autotests/integration/move_resize_window_test.cpp M +2 -2 autotests/integration/outputchanges_test.cpp M +7 -7 autotests/integration/quick_tiling_test.cpp M +1 -1 src/placement.cpp M +1 -10 src/placementtracker.cpp M +65 -65 src/window.cpp M +3 -7 src/window.h https://invent.kde.org/plasma/kwin/-/commit/370c9c895373838cb5d4b51ff26ad9b54f3f9ef5
The underlying issue in Qt is still there, but the bug doesn't happen anymore with the commit, so I'm closing this
*** Bug 491812 has been marked as a duplicate of this bug. ***
Can this be included/backported in 6.1.5? 2 months with disappearing windows is quite long.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6306
Git commit dd5b7d6e6df01d2c07bc8b96374fbf46f5c333ce by Xaver Hugl. Committed on 22/08/2024 at 21:12. Pushed by zamundaaa into branch 'Plasma/6.1'. window: make setQuickTileMode more sane ...by removing the keyboard flag, moving keyboard shortcut handling into a separate method and making the position to tile the window at explicit This also means KWin doesn't do as many intermediary changes to window geometry on output hotplugs, which may work around some clients not always reacting to no-op changes. (cherry picked from commit 370c9c895373838cb5d4b51ff26ad9b54f3f9ef5) M +1 -1 autotests/integration/move_resize_window_test.cpp M +2 -2 autotests/integration/outputchanges_test.cpp M +7 -7 autotests/integration/quick_tiling_test.cpp M +1 -1 src/placement.cpp M +1 -10 src/placementtracker.cpp M +65 -65 src/window.cpp M +3 -7 src/window.h https://invent.kde.org/plasma/kwin/-/commit/dd5b7d6e6df01d2c07bc8b96374fbf46f5c333ce
*** Bug 492244 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6349
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6350
Git commit 24ab95bdd76dd189aa9a190d75f19ee94f733077 by Xaver Hugl. Committed on 03/09/2024 at 13:29. Pushed by zamundaaa into branch 'master'. workspace: don't rearrange immediately when a window with struts gets removed Otherwise, rearrange can happen on intermediate output configurations, as layer shell windows can get closed in response to outputs being disabled. That rearrange on intermediate output configurations can confuse the placement tracker logic, which may then move windows to weird locations or even offscreen M +1 -1 src/workspace.cpp https://invent.kde.org/plasma/kwin/-/commit/24ab95bdd76dd189aa9a190d75f19ee94f733077
Git commit 4b1caed5644bf34aabfa7af533d19fad420568d5 by Xaver Hugl. Committed on 03/09/2024 at 13:43. Pushed by zamundaaa into branch 'Plasma/6.1'. workspace: don't rearrange immediately when a window with struts gets removed Otherwise, rearrange can happen on intermediate output configurations, as layer shell windows can get closed in response to outputs being disabled. That rearrange on intermediate output configurations can confuse the placement tracker logic, which may then move windows to weird locations or even offscreen (cherry picked from commit 24ab95bdd76dd189aa9a190d75f19ee94f733077) Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> M +1 -1 src/workspace.cpp https://invent.kde.org/plasma/kwin/-/commit/4b1caed5644bf34aabfa7af533d19fad420568d5