Bug 411884 - In wayland BorderlessMaximizedWindows can cause window to not receive input
Summary: In wayland BorderlessMaximizedWindows can cause window to not receive input
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: decorations (show other bugs)
Version: git master
Platform: Other Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Andrey
URL: https://invent.kde.org/plasma/kwin/-/...
Keywords: wayland
: 439004 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-09-13 09:08 UTC by Méven Car
Modified: 2021-12-17 07:34 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.23.2


Attachments
wayland debug on maximize button click (5.89 KB, text/plain)
2021-07-06 22:02 UTC, Andrey
Details
on surface re-entering, the problem is gone (356 bytes, text/plain)
2021-07-06 22:12 UTC, Andrey
Details
maximize with borders (no bug here) (4.59 KB, text/plain)
2021-07-08 14:40 UTC, Andrey
Details
maximize on decoration double click (no bug) (3.93 KB, text/plain)
2021-07-08 20:55 UTC, Andrey
Details
maximize on keyboard shortcut (no bug) (4.40 KB, text/plain)
2021-07-08 21:30 UTC, Andrey
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Méven Car 2019-09-13 09:08:32 UTC
SUMMARY

With BorderlessMaximizedWindows, when clicking on a maximize button, makes the window not receive inputs events.

STEPS TO REPRODUCE
1. With kwin_wayland having started with [Windows] BorderlessMaximizedWindows=true in ~/.config/kwinrc
2. Click on the maximize button

OBSERVED RESULT
The maximized window does not receive mouse or keyboard events.

EXPECTED RESULT
The maximized window receives mouse or keyboard events.

The feature works normally when one drags a window on the top border to maximize it.
It seems like a focus issue.

Operating System: Kubuntu 19.04
KDE Plasma Version: 5.16.80
KDE Frameworks Version: 5.62.0
Qt Version: 5.12.2
Comment 1 Martin Kostolný 2020-01-23 18:21:39 UTC
I'm having similar issue with mouse input but keyboard events are always received. I also did a bit experimenting. Sometimes it can be triggered with keyboard shortcut for maximalization, too.

When the issue is triggered (meaning mouse input in maximized app is lost), the moment you hover plasma panel with mouse (or switch windows / desktop) -> mouse input in maximized window is back. That is a kind of workaround :-).

System: gentoo, Plasma 5.17.4, KF 5.66, Qt 5.13.2
Comment 2 Janet Blackquill 2020-03-31 15:18:46 UTC
Can reproduce on git master.
Comment 3 Patrick Silva 2020-06-15 17:30:26 UTC
keyboard input works with Kate at least.
Mouse input doesn't work if Kate is maximized with click on maximize button.
It works if Kate is maximized with double click on its window decoration instead.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.19.80
KDE Frameworks Version: 5.71.0
Qt Version: 5.14.2
Comment 4 Andrey 2021-07-06 22:02:49 UTC
Created attachment 139910 [details]
wayland debug on maximize button click

It seems like wl_pointer@20.enter() is missing when the problem arises
Comment 5 Andrey 2021-07-06 22:12:11 UTC
Created attachment 139911 [details]
on surface re-entering, the problem is gone

..which happens on surface re-entering, producing the workaround above
Comment 6 Andrey 2021-07-06 22:19:15 UTC
(In reply to Martin Kostolný from comment #1)
> Sometimes it can be triggered with
> keyboard shortcut for maximalization, too.
I didn't managed to reproduce with keyboard shortcut, could you help?
Comment 7 Andrey 2021-07-08 14:40:37 UTC
Created attachment 139953 [details]
maximize with borders (no bug here)
Comment 8 Andrey 2021-07-08 20:55:11 UTC
Created attachment 139959 [details]
maximize on decoration double click (no bug)
Comment 9 Andrey 2021-07-08 21:30:52 UTC
Created attachment 139960 [details]
maximize on keyboard shortcut (no bug)
Comment 10 Andrey 2021-07-20 22:31:56 UTC
I don't know why the fixes didn't get posted here,
added manually:
https://invent.kde.org/plasma/kwin/-/merge_requests/1167
Comment 11 Nate Graham 2021-07-28 20:02:52 UTC
*** Bug 439008 has been marked as a duplicate of this bug. ***
Comment 12 Nate Graham 2021-07-28 20:06:35 UTC
*** Bug 439004 has been marked as a duplicate of this bug. ***
Comment 13 Nate Graham 2021-07-29 14:30:25 UTC
*** Bug 440380 has been marked as a duplicate of this bug. ***
Comment 14 AlexDeLorenzo.dev 2021-10-04 02:30:57 UTC
This issue affects the excellent Window Buttons Applet[1] by Psifidotos, which is the 4th highest rated Plasma applet on the KDE Store[2].

In order to interact with maximized windows, users can bring another window into focus, and then switch back to the maximized window.

> I don't know why the fixes didn't get posted here,
> added manually:
> https://invent.kde.org/plasma/kwin/-/merge_requests/1167

Thanks for working on a solution, Andrey. I'm looking forward to your fix being merged.

[1] https://github.com/psifidotos/applet-window-buttons

[2] https://store.kde.org/p/1272871(In reply to Andrey from comment #10)
Comment 15 Bug Janitor Service 2021-10-18 19:15:29 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1543
Comment 16 Andrey 2021-10-22 09:49:29 UTC
Git commit 83ece2e2a831b9dd8d872f7d94317075018c1d62 by Andrey Butirsky.
Committed on 22/10/2021 at 09:47.
Pushed by butirsky into branch 'master'.

unit test for focusing loss problem on maximize

M  +96   -1    autotests/integration/pointer_input.cpp

https://invent.kde.org/plasma/kwin/commit/83ece2e2a831b9dd8d872f7d94317075018c1d62
Comment 17 Andrey 2021-10-22 09:49:37 UTC
Git commit e4e920d89514887d51491d47d4311748559e2933 by Andrey Butirsky.
Committed on 22/10/2021 at 09:47.
Pushed by butirsky into branch 'master'.

[testBorderlessMaximizedWindow] add touch to the test

M  +94   -1    autotests/integration/touch_input_test.cpp

https://invent.kde.org/plasma/kwin/commit/e4e920d89514887d51491d47d4311748559e2933
Comment 18 Andrey 2021-10-22 09:49:45 UTC
Git commit 566bfbff5b84719a975117f5fb4fa1cef76621ae by Andrey Butirsky, on behalf of David Edmundson.
Committed on 22/10/2021 at 09:47.
Pushed by butirsky into branch 'master'.

Fix focus loss on decoration destruction

InputDeviceHandler keeps track of which client has focus, and whether
the decoration or main window has focus.

Should the decoration get destroyed whilst the decoration has focus we
don't update correctly. This can happen when
"BorderlessMaximizedWindows" is set, or if you use key presses whilst
above the decoration.

cleanupDecoration (which is an odd name) is called whenever a decoration
gains or loses focus. Here we can connect for the decoration destruction
and force a focus change.

M  +6    -0    src/pointer_input.cpp
M  +1    -0    src/pointer_input.h

https://invent.kde.org/plasma/kwin/commit/566bfbff5b84719a975117f5fb4fa1cef76621ae
Comment 19 Andrey 2021-10-22 09:51:36 UTC
Git commit d87273d8114c4abc72b518ebd300fd67b33a3625 by Andrey Butirsky, on behalf of David Edmundson.
Committed on 22/10/2021 at 09:51.
Pushed by butirsky into branch 'Plasma/5.23'.

Fix focus loss on decoration destruction

InputDeviceHandler keeps track of which client has focus, and whether
the decoration or main window has focus.

Should the decoration get destroyed whilst the decoration has focus we
don't update correctly. This can happen when
"BorderlessMaximizedWindows" is set, or if you use key presses whilst
above the decoration.

cleanupDecoration (which is an odd name) is called whenever a decoration
gains or loses focus. Here we can connect for the decoration destruction
and force a focus change.


(cherry picked from commit 566bfbff5b84719a975117f5fb4fa1cef76621ae)

M  +6    -0    src/pointer_input.cpp
M  +1    -0    src/pointer_input.h

https://invent.kde.org/plasma/kwin/commit/d87273d8114c4abc72b518ebd300fd67b33a3625
Comment 20 p d 2021-10-27 05:42:36 UTC
The bug is not fixed fully. I still have the issue half the time, and when I maximize by double clicking the address bar, I have the issue all the time.
Comment 21 Andrey 2021-10-27 07:28:02 UTC
p-d, are you completely sure you have the patch?
Anyone else has the problem?
Comment 22 p d 2021-10-27 07:34:11 UTC
I have KDE 5.23.2, that is supposed to include the patch, is it not?

Operating System: Fedora Linux 35
KDE Plasma Version: 5.23.2
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.14.14-300.fc35.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
Comment 23 p d 2021-10-27 07:35:54 UTC
With "Hide Titles" kwin script, the issue still happens some of the time.
Comment 24 Méven Car 2021-10-27 09:01:50 UTC
(In reply to Andrey from comment #21)
> p-d, are you completely sure you have the patch?
> Anyone else has the problem?

It is part of Plasma 5.23.2 https://kde.org/announcements/changelogs/plasma/5/5.23.1-5.23.2/
Comment 25 Méven Car 2021-10-27 09:07:30 UTC
(In reply to p d from comment #23)
> With "Hide Titles" kwin script

That's this one I guess:
https://store.kde.org/p/1354715/
https://github.com/bahamondev/hide-titles/blob/master/contents/code/main.js

> the issue still happens some of the time.

Do you know if that is when you click the maximize button or drap up a window, or double click on a window title bar ?
Comment 26 Méven Car 2021-10-27 09:12:09 UTC
(In reply to Méven Car from comment #25)
> (In reply to p d from comment #23)
> > With "Hide Titles" kwin script
> 
> That's this one I guess:
> https://store.kde.org/p/1354715/
> https://github.com/bahamondev/hide-titles/blob/master/contents/code/main.js
> 
> > the issue still happens some of the time.
> 
> Do you know if that is when you click the maximize button or drap up a
> window, or double click on a window title bar ?

That's a different bug this one concerned specifically the "BorderlessMaximizedWindows" case.
Comment 27 p d 2021-10-28 07:53:58 UTC
(In reply to Méven Car from comment #25)
> (In reply to p d from comment #23)
> > With "Hide Titles" kwin script
> 
> That's this one I guess:
> https://store.kde.org/p/1354715/
> https://github.com/bahamondev/hide-titles/blob/master/contents/code/main.js
> 
> > the issue still happens some of the time.
> 
> Do you know if that is when you click the maximize button or drap up a
> window, or double click on a window title bar ?

It happens sometimes with any of those actions.
Comment 28 p d 2021-10-28 07:54:24 UTC
(In reply to Méven Car from comment #26)
> (In reply to Méven Car from comment #25)
> > (In reply to p d from comment #23)
> > > With "Hide Titles" kwin script
> > 
> > That's this one I guess:
> > https://store.kde.org/p/1354715/
> > https://github.com/bahamondev/hide-titles/blob/master/contents/code/main.js
> > 
> > > the issue still happens some of the time.
> > 
> > Do you know if that is when you click the maximize button or drap up a
> > window, or double click on a window title bar ?
> 
> That's a different bug this one concerned specifically the
> "BorderlessMaximizedWindows" case.

Then why was my bug ( https://bugs.kde.org/show_bug.cgi?id=440380 ) marked duplicate of this bug, if it's a different bug?
Comment 29 Méven Car 2021-10-28 08:56:48 UTC
(In reply to p d from comment #28)
> (In reply to Méven Car from comment #26)
> > (In reply to Méven Car from comment #25)
> > > (In reply to p d from comment #23)
> > > > With "Hide Titles" kwin script
> > > 
> > > That's this one I guess:
> > > https://store.kde.org/p/1354715/
> > > https://github.com/bahamondev/hide-titles/blob/master/contents/code/main.js
> > > 
> > > > the issue still happens some of the time.
> > > 
> > > Do you know if that is when you click the maximize button or drap up a
> > > window, or double click on a window title bar ?
> > 
> > That's a different bug this one concerned specifically the
> > "BorderlessMaximizedWindows" case.
> 
> Then why was my bug ( https://bugs.kde.org/show_bug.cgi?id=440380 ) marked
> duplicate of this bug, if it's a different bug?

Because bug triaging is an art and not science ^^

Mistakes happens

I have reopened your bug with the script scenario.
Comment 30 aliceaccounts 2021-11-28 15:00:35 UTC
I can still reproduce this bug on plasma 5.23.3
Comment 31 Andrey 2021-11-29 09:29:55 UTC
It must be https://invent.kde.org/plasma/kwin/-/merge_requests/1583 patch which regressed the fix and the unit tests.
Vlad, do you have an idea how to fix it again?
Comment 32 AlexDeLorenzo.dev 2021-12-14 05:36:21 UTC
I'm running into this issue, just less frequently now.

When maximizing windows via the Window AppMenu widget, I no longer encounter this issue. When I use the maximize button on window decorations, or double click the window's title bar, the maximized window doesn't respond to mouse input. 

However, now I only have to click on a Plasma panel widget in order for the window to grab mouse input again. Before I had to completely switch windows and then go back to get the mouse to work.

KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.88.0
Qt Version: 5.15.2
Graphics Platform: Wayland
Comment 33 Bug Janitor Service 2021-12-15 15:27:09 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1800
Comment 34 Vlad Zahorodnii 2021-12-17 07:34:09 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 440380

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

https://invent.kde.org/plasma/kwin/commit/41237ea30bc7146402127046ba388785e04b0c74