Created attachment 188625 [details] borderless window inside plasma panel SUMMARY A maximized borderless window ends up inside the Plasma panel if the display is turned off and then turned on (see attached screenshot). This does not always happen; however, I have found a specific reproducible condition that triggers this behavior every time. STEPS TO REPRODUCE You will need two monitors. In my case, HDMI-A-1 (right) is the primary monitor, and HDMI-A-2 is the secondary monitor (see screenshot for my configuration). Also, enable "Turn off screen - When locked: Immediately" in Power Management. 1. Place a maximized borderless window on the secondary monitor. It will not overlap with the panel at this stage (I was using Firefox). 2. Move the mouse to the primary monitor and click once to make the borderless window inactive. 3. Press the lock screen shortcut. Both screens will lock and then immediately turn off. 4. Move your mouse to wake the screens. Notice that the cursor suddenly warps to the secondary monitor, even though it was on the primary one before. Enter your password to unlock the screen. 5. Observe that the Firefox window is now inside the Plasma panel. SOFTWARE/OS VERSIONS Operating System: NixOS 26.05 KDE Plasma Version: 6.5.4 KDE Frameworks Version: 6.22.0 Qt Version: 6.10.1 Kernel Version: 6.12.64-xanmod1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 6900HX with Radeon Graphics Memory: 32 GiB of RAM (30.6 GiB usable) Graphics Processor: AMD Radeon RX 6650M
is it really without border or is the border there, but hidden under the panel?
(In reply to Marco Martin from comment #1) > is it really without border or is the border there, but hidden under the > panel? If I drag the bugged Firefox window out of the panel, its style visually remains the same. It does not have a system title bar or borders. It might be a problem specific to Firefox (or its rendering toolkit). I wasn't able to reproduce this issue with PyCharm (running via xwayland, "Merge main menu with window title" enabled) or VS Code (should be running wayland, but I'm not sure). Also, I have noticed that Firefox acts weirdly when it is unmaximized; for a brief moment, the window becomes huge. It feels like something is wrong with geometry calculations somewhere. It happens with animations disabled as well. Example: https://imgur.com/a/RxIB3Pb
Telegram desktop also shows the same behaviour; it gets stuck inside the panel. So I guess it's not Firefox-specific.
The key thing is to see what we're telling the app to do. It'll help identify where the bug is. As you can reliably reproduce can you run: WAYLAND_DEBUG=1 firefox 2> bug_log and then attach that new file here. and reproduce this issue. Try to avoid too many other window moves after the screens turn on and off.
Created attachment 188754 [details] Output of "WAYLAND_DEBUG=1 firefox 2> firefox_bug.log" Gemini suggests that compositor sometimes loses track of the reserved screen space (struts) for the panel during the lock/unlock phase: [3537694.464] {Default Queue} xdg_toplevel#61.configure(1920, 1040, array[4]) ... [3544889.714] {Default Queue} xdg_toplevel#61.configure(1920, 1080, array[12])
Created attachment 188755 [details] Output of "WAYLAND_DEBUG=1 Telegram 2> telegram_bug.log" Something similar here: [ 356642.408] {Default Queue} xdg_toplevel#50.configure(1920, 1040, array[8]) ... [ 364114.853] {Default Queue} xdg_toplevel#50.configure(1920, 1080, array[8])