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

Can reproduce on git master.

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

Created attachment 139910 [details]
wayland debug on maximize button click

It seems like wl_pointer@20.enter() is missing when the problem arises

Created attachment 139911 [details]
on surface re-entering, the problem is gone

..which happens on surface re-entering, producing the workaround above

(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?

Created attachment 139953 [details]
maximize with borders (no bug here)

Created attachment 139959 [details]
maximize on decoration double click (no bug)

Created attachment 139960 [details]
maximize on keyboard shortcut (no bug)

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

*** Bug 439008 has been marked as a duplicate of this bug. ***

*** Bug 439004 has been marked as a duplicate of this bug. ***

*** Bug 440380 has been marked as a duplicate of this bug. ***

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)

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1543

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

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

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

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

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.

p-d, are you completely sure you have the patch?
Anyone else has the problem?

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

With "Hide Titles" kwin script, the issue still happens some of the time.

(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/

(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 ?

(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.

(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.

(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?

(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.

I can still reproduce this bug on plasma 5.23.3

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?

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

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1800

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