Bug 440380 - Maximized windows are temporarily unresponsive when hiding titlebar for maximized windows in wayland
Summary: Maximized windows are temporarily unresponsive when hiding titlebar for maxim...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 5.22.4
Platform: Other Other
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-29 09:40 UTC by p d
Modified: 2022-01-09 08:54 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.24


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description p d 2021-07-29 09:40:48 UTC
SUMMARY

I using Fedora KDE with Wayland, stock repos. If I enable a kwin script that hides the titlebar for maximized windows, or I use the "Window Buttons" 3rd party plasmoid, and enable that setting inside it's options, when I first maximize a window (using a window's own maximize buttons), I can't click on anything in the program window. The contents of the window is unresponsive. If I minimize and maximize the window again, I can suddenly interact with the program window.

A workaround on the top panel is to activate the "Windows Go Below" panel setting, but it's not ideal.

This problem does not happen on X11.

STEPS TO REPRODUCE
1. Use KDE Wayland and enable a kwin script that hides maximized windows' titlebar
2. Maximize the window with the window's titlebar button's (not any other maximize panel button)
3. Notice you can't click on anything inside the window until you minimize, maximize again.

OBSERVED RESULT

See above.

EXPECTED RESULT

For program windows to be responsive when such kwin script is activated and maximizing the window for the first time.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 

Operating System: Fedora 34
KDE Plasma Version: 5.22.4
KDE Frameworks Version: 5.83.0
Qt Version: 5.15.2
Kernel Version: 5.13.5-200.fc34.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-7300U CPU @ 2.60GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 620


ADDITIONAL INFORMATION
Comment 1 Nate Graham 2021-07-29 14:30:25 UTC

*** This bug has been marked as a duplicate of bug 411884 ***
Comment 3 Vlad Zahorodnii 2021-12-17 07:34:17 UTC
Git commit 41237ea30bc7146402127046ba388785e04b0c74 by Vlad Zahorodnii.
Committed on 17/12/2021 at 07:19.
Pushed by vladz into branch 'master'.

Ignore decoration when updating focused window in PointerInput and TouchInput

Currently, it's possible to have the case where the pointer input device
handler or the touch input device handler thinks that there's a focused
window, but the corresponding focused surface in wayland seat is unset,
because the pointer hovers the server side decoration.

If the server side decoration is destroyed, the input device handler will
fail to update wayland seat's focused surface.

In order to make pointer input device handler and touch input device
handler code more intuitive, this change makes focusUpdate() functions
ignore the decoration.
Related: bug 411884

M  +1    -3    src/pointer_input.cpp
M  +1    -2    src/touch_input.cpp

https://invent.kde.org/plasma/kwin/commit/41237ea30bc7146402127046ba388785e04b0c74
Comment 4 Aleksey Zagorodnikov 2022-01-09 08:20:05 UTC
Hi, I've recently switched to wayland and now experiencing this problem. It is marked as resolved, but in my case it is definitely here.
I'm using dual monitor setup if it matter.

Operating System: Manjaro Linux
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.89.0
Qt Version: 5.15.2
Kernel Version: 5.15.13-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 12 × Genuine Intel® CPU 0000 @ 3.20GHz
Memory: 31,0 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 630
Comment 5 Aleksey Zagorodnikov 2022-01-09 08:54:35 UTC
I'm so sorry, didn't realized that fix is not released yet in 5.23.5