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
sill happening to me. using fedora 41, plasma 6.1.5 it happened when had the windows on the external monitor, and disconnected after the computer entered sleep mode.
I too have continued to see this on master as well. Re-opening.
For me, the affected app windows are almost always Firefox, Thunderbird, and NeoChat.
Still happening (a lot) on 6.2.4-1 (Arch Linux) My setup is a Laptop and the external screen is connected via USB-C/DP. AMD Ryzen 7 PRO 5850U with Radeon Graphics, open source drivers, 6.12.1 kernel. For me I can definitely add Konsole / Alacritty to the window types affected. If the window was maximized on the disconnected display, the "maximized state" can be seen via task bar context menu, but not removed. Maximized windows can not be moved to the current screen, neither by keyboard shortcuts nor by selecting the "Move" action. Left clicking on the task bar icon i still get a minimization effect rendered and i can see the window "coming in" from the missing external display and going back "there". So window positions seem to be intact somehow. Just no monitor to render it then :) Some journal entries on display disconnect / resume into a lost window. Thunderbird was never on the external display, Firefox might had a window there but all reachable. One fullscreen window of Alacritty is lost. ``` Dez 12 16:49:53 hostname kernel: usb 3-1: USB disconnect, device number 6 Dez 12 16:49:53 hostname thunderbird[2041]: [Parent 2041, Main Thread] WARNING: Couldn't map window 0x747a27c04da0 as subsurface because its parent is not mapped.: 'glib warning', file /usr/src/debug/thunderbird/thunderbird-128.4.4/toolkit/xre/nsSigHandlers.cpp:187 [...] Dez 12 16:49:53 hostname thunderbird[2041]: Couldn't map window 0x747a2aa9d3e0 as subsurface because its parent is not mapped. Dez 12 16:49:53 hostname firefox[2034]: [Parent 2034, Main Thread] WARNING: Couldn't map window 0x7a6239415300 as subsurface because its parent is not mapped.: 'glib warning', file /usr/src/debug/firefox/firefox-133.0/toolkit/xre/nsSigHandlers.cpp:201 [...] Dez 12 16:49:53 hostname thunderbird[2041]: [Parent 2041, Main Thread] WARNING: Couldn't map window 0x747a27c055c0 as subsurface because its parent is not mapped.: 'glib warning', file /usr/src/debug/thunderbird/thunderbird-128.4.4/toolkit/xre/nsSigHandlers.cpp:187 [...] Dez 12 16:49:53 hostname thunderbird[2041]: Couldn't map window 0x747a2d540da0 as subsurface because its parent is not mapped. Dez 12 16:49:53 hostname firefox[2034]: Couldn't map window 0x7a6239415300 as subsurface because its parent is not mapped. [lots of the same] [...] [suspended] [...] Dez 13 09:25:32 hostname kwin_wayland[1407]: kwin_scene_opengl: 0x2: GL_INVALID_OPERATION in glDrawBuffers(unsupported buffer GL_BACK_LEFT) Dez 13 09:25:32 hostname kwin_wayland[1407]: kwin_scene_opengl: 0x2: GL_INVALID_OPERATION in glDrawBuffers(unsupported buffer GL_BACK_LEFT) [...LOTS OF IT... on every window switcher instantiation - unrelated? seemingly works fine anyway] Dez 13 09:25:33 hostname kwin_wayland[1407]: kwin_core: Cannot grant a token to KWin::ClientConnection(0x573344ef3ad0) [lots of these, always the same address, in my current state i have exactly one "lost" window that i can not reach anymore] ```
(In reply to Sebastian Goth from comment #33) > Dez 13 09:25:32 hostname kwin_wayland[1407]: kwin_scene_opengl: 0x2: > GL_INVALID_OPERATION in glDrawBuffers(unsupported buffer GL_BACK_LEFT) > Dez 13 09:25:32 hostname kwin_wayland[1407]: kwin_scene_opengl: 0x2: > GL_INVALID_OPERATION in glDrawBuffers(unsupported buffer GL_BACK_LEFT) > [...LOTS OF IT... on every window switcher instantiation - unrelated? > seemingly works fine anyway] Yeah that's unrelated. To move forward with this, we need someone to provide a reproducible case - ideally with exact numbers on window and screen geometries, and the exact sequence of hotplug events, so that we can put that into an autotest and have something to work with. Starting the app that gets stuck offscreen with WAYLAND_DEBUG=1 and attaching the output of that here could also be useful.
FWIW for me this is fully fixed in git master.
Created attachment 176744 [details] wayland debug output of vanished window (In reply to Zamundaaa from comment #34) > To move forward with this, we need someone to provide a reproducible case - > ideally with exact numbers on window and screen geometries, and the exact > sequence of hotplug events, so that we can put that into an autotest and > have something to work with. > Starting the app that gets stuck offscreen with WAYLAND_DEBUG=1 and > attaching the output of that here could also be useful. This is the output of: WAYLAND_DEBUG=1 alacritty 2>&1 | tee Screen1: Laptop monitor Screen2: External monitor connected via USB-C Steps that made it vanish: - On VirtualDesktop2 - Start app on Screen1 - Move app to Screen2 - Maximize app - Switch to VirtualDesktop1 - Disconnect external monitor Log shows me trying to interact with the vanished Window shortly Then attaching the monitor again
yeah, that's definitely working fine on git master. If you still experience it anyways in 6.3, just reopen this
Fixed for me too with 6.2.90
still happening to me on 6.2.90 1. windows on second monitor 2. put laptop to sleep 3. disconnect second monitor 4. wake the laptop
Actually happened to me again with 6.2.90 too Steps: Window maximized on virtual desktop 2 on internal laptop display (only display at that time) Switch to virtual desktop 1 Put laptop to sleep Wake up laptop without login Attach external monitor Close laptop lid (disable internal display) Login Switch to virtual desktop 2 -> Maximized window is still on laptop display