Bug 442534 - Maximized window does not move to another moniroe
Summary: Maximized window does not move to another moniroe
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.22.90
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: regression
: 442363 442615 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-09-16 15:04 UTC by d3coder
Modified: 2021-09-17 20:32 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.23
Sentry Crash Report:
vlad.zahorodnii: Wayland-
vlad.zahorodnii: X11+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description d3coder 2021-09-16 15:04:20 UTC
SUMMARY
Window does not move to the next monitor if window is maximized
Bind "Move window to next monitor" action to some hotkey, meta + space in my case

STEPS TO REPRODUCE
1. Maximize window
2. Press meta + space

OBSERVED RESULT
1. Firefox does not move another monitor, "move" animation works, but window simply becomes smaller as if it's about to move and then maximizes back
2. Full screen firefox does move to another monitor without animation
3. Freshly started dolphin does not play "moving" animation and does not move to another monitor
if i restore and maximize dolphin, it plays "moving" animation, but does not actually move to another monitor

EXPECTED RESULT
Window moves to another monitor

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.22.90
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Kernel Version: 5.14.3-arch1-1 (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics 4600

ADDITIONAL INFORMATION
Comment 1 Bug Janitor Service 2021-09-17 09:28:10 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1428
Comment 2 Vlad Zahorodnii 2021-09-17 14:02:23 UTC
Git commit afcb9fd037937d948ea4dcf411518155ec149acb by Vlad Zahorodnii.
Committed on 17/09/2021 at 14:02.
Pushed by vladz into branch 'master'.

x11: Fix "Move window to next screen" shortcut for maximized windows

With the recent AbstractOutput changes, Workspace::clientArea() overload
that takes only the window and no additional output was changed to

    return clientArea(opt, window, window->output());

prior to that, it had been looking up the output at the center of the
frame geometry.

As it turns out, AbstractOutput::sendToOutput() blocks geometry updates,
which in its turn means that Toplevel::output() will be updated only
after geometry updates are unblocked. For the most part, it's not a big
deal until you need to use Workspace::clientArea(opt, const Toplevel*)

Since the output won't be updated until geometry updates are unblocked,
clientArea(opt, const Toplevel *) may return outdated info.

One could argue that we just simply need to update m_output similar to
m_frameGeometry when geometry updates are blocked, but... it's not going
to work on wayland! On Wayland, GeometryUpdatesBlocker is totally
unnecessary. Even if a window is resized, m_frameGeometry will be left
unchanged until the client repaints the window.

Instead, one need to pass the AbstractOutput to clientArea() if it's
important.

This change makes X11Client::changeMaximize() query the MaximizeArea of
the output containing the center of the move resize geometry, similar to
what the XdgToplevelClient does.

M  +1    -1    src/x11client.cpp

https://invent.kde.org/plasma/kwin/commit/afcb9fd037937d948ea4dcf411518155ec149acb
Comment 3 Vlad Zahorodnii 2021-09-17 14:02:53 UTC
Git commit cc006d3f8e76e55bafd5ebc09013b1b356aea967 by Vlad Zahorodnii.
Committed on 17/09/2021 at 14:02.
Pushed by vladz into branch 'Plasma/5.23'.

x11: Fix "Move window to next screen" shortcut for maximized windows

With the recent AbstractOutput changes, Workspace::clientArea() overload
that takes only the window and no additional output was changed to

    return clientArea(opt, window, window->output());

prior to that, it had been looking up the output at the center of the
frame geometry.

As it turns out, AbstractOutput::sendToOutput() blocks geometry updates,
which in its turn means that Toplevel::output() will be updated only
after geometry updates are unblocked. For the most part, it's not a big
deal until you need to use Workspace::clientArea(opt, const Toplevel*)

Since the output won't be updated until geometry updates are unblocked,
clientArea(opt, const Toplevel *) may return outdated info.

One could argue that we just simply need to update m_output similar to
m_frameGeometry when geometry updates are blocked, but... it's not going
to work on wayland! On Wayland, GeometryUpdatesBlocker is totally
unnecessary. Even if a window is resized, m_frameGeometry will be left
unchanged until the client repaints the window.

Instead, one need to pass the AbstractOutput to clientArea() if it's
important.

This change makes X11Client::changeMaximize() query the MaximizeArea of
the output containing the center of the move resize geometry, similar to
what the XdgToplevelClient does.


(cherry picked from commit afcb9fd037937d948ea4dcf411518155ec149acb)

M  +1    -1    src/x11client.cpp

https://invent.kde.org/plasma/kwin/commit/cc006d3f8e76e55bafd5ebc09013b1b356aea967
Comment 4 Siddhartha 2021-09-17 20:06:43 UTC
*** Bug 442363 has been marked as a duplicate of this bug. ***
Comment 5 Siddhartha 2021-09-17 20:32:28 UTC
*** Bug 442615 has been marked as a duplicate of this bug. ***