Bug 370510 - Can't move windows to 2nd monitor - stuck at panel border
Summary: Can't move windows to 2nd monitor - stuck at panel border
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: 5.8.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 374263 376168 391279 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-10-11 21:17 UTC by Emre
Modified: 2018-03-03 06:34 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot that shows the problem (31.65 KB, image/jpeg)
2016-10-11 21:18 UTC, Emre
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Emre 2016-10-11 21:17:35 UTC
I have a two monitor setup. Laptop screen eDP1 is below the HDMI screen. Xrandr is like this:
xrandr --output eDP1 --auto --below HDMI1 --output HDMI1 --auto --primary                             

Large Monitor on HDMI is the primary one, it has the taskbar/panel 100% of the width. The panel is at the bottom edge of the HDMI monitor. 
The Laptop Monitor on eDP1  does not have any panels, just empty.

When I try to move a window using my mouse from the top monitor, through the panel, to the bottom monitor, the window goes but gets stuck at the panel. So the window is essentially trapped in the top monitor.

If I use the Move To Screen - Screen Two (eDP1) command on the top left icon of that window, the window moves. 

Hope I'm not the only one using Top-Bottom monitor configurations :)

Reproducible: Always
Comment 1 Emre 2016-10-11 21:18:50 UTC
Created attachment 101529 [details]
Screenshot that shows the problem
Comment 2 Martin Flöser 2016-10-12 05:34:16 UTC
You should be able to move the window using Alt+ left mouse button.

Overall that's a protection. One cannot move the window decoration underneath a panel. This is the intended behavior to make sure that you cannot move a window out of view and that one always can move the window. Not sure what to do here as changing that could become dangerous by breaking the protection.
Comment 3 Emre 2016-10-12 09:58:03 UTC
Thanks Martin for the response and the ALT+LEFT_MOUSE tip. That helps as a workaround although one that requires an extra step each time you want to move a window.

In MS Windows desktops no such problem exists. I do not understand what you mean that it's a protection. In years of Windows use, never faced such issue. By the time the last pixel row comes to the panel it jumps to second screen.
Comment 4 luke.nukem.jones@gmail.com 2016-10-15 21:31:53 UTC
Emre, I'm curious - does this problem still happen if you move the panel to the top? It sounds as if it is related to the panel trapping a mouse event.
Comment 5 Emre 2016-10-16 08:56:56 UTC
Hi Luke, no, when the panel is at the top, that problem does not exist. Windows can freely move between monitors. 
The workaround that Martin has given works well. If you click ALT before you click the window titlebar, then you can move the window to the other monitor passing under the panel.
Comment 6 luke.nukem.jones@gmail.com 2016-10-16 09:03:15 UTC
(In reply to Emre from comment #5)
> Hi Luke, no, when the panel is at the top, that problem does not exist.
> Windows can freely move between monitors. 
> The workaround that Martin has given works well. If you click ALT before you
> click the window titlebar, then you can move the window to the other monitor
> passing under the panel.

As I suspected then. You'll find that the panel blocks any window being dragged by the titlebar, regardless of where the panel is. The question is if this behaviour should be removed or not.
Comment 7 Martin Flöser 2016-10-16 15:40:26 UTC
> You'll find that the panel blocks any window being dragged by the titlebar, regardless of where the panel is. The question is if this behaviour should be removed or not.

This is the protection I talked about. It is the intended behavior and will not be changed in general. The only question is whether we can make it work better in the multi-screen case.
Comment 8 Martin Flöser 2017-01-01 09:29:54 UTC
*** Bug 374263 has been marked as a duplicate of this bug. ***
Comment 9 Christoph Feck 2017-03-31 21:01:20 UTC
*** Bug 376168 has been marked as a duplicate of this bug. ***
Comment 10 Martin Flöser 2017-07-08 06:52:31 UTC
I created a patch for bug #371199 which might address also this problem: https://phabricator.kde.org/D6562

I'm not sure whether it can also fix this problem here as it is slightly different.
Comment 11 Martin Flöser 2017-07-11 15:52:32 UTC
Git commit 14c8440f11f9af48e63ca0fcf05ee7988f445b9a by Martin Flöser.
Committed on 11/07/2017 at 15:51.
Pushed by graesslin into branch 'master'.

Restrict move resize area only on the screen the strut window is on

Summary:
By allowing panels between screens in 5.8 to have a strut we created a
"regression" in KWin. KWin always was wrong, just we didn't notice as
neither Plasma nor previously Kicker set a strut on panels between shared
screen edges.

The strut is created from the edge of the overall screen setup. This
means a panel on the left edge of a screen on the right has the strut
starting from the left screen. KWin uses the strut to restrict the move
resize area: a window decoration is not allowed to go below a strut. Thus
it becomes impossible to move the window from the right to the left
screen.

This change tries to solve this problem by only restricting the move area
on the screen the window with the strut is on. E.g. if the window is on
the right screen, the left screen is not affected. Thus it's possible
again to move a window from one screen to the other as the added test
case shows.

Unfortunately there are still corner cases where this won't work
correctly. If the window is on both screens this won't work. It is also a
rather heavy change for KWin and thus it's targeted for master and not
for the 5.10 or the 5.8 branch. If we notice that the patch works well
and doesn't create further issues, it should be considered for
backporting.
Related: bug 371199
FIXED-IN: 5.11

Test Plan: Added test case

Reviewers: #kwin, #plasma

Subscribers: plasma-devel, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D6562

M  +151  -19   autotests/integration/struts_test.cpp
M  +4    -0    geometry.cpp

https://commits.kde.org/kwin/14c8440f11f9af48e63ca0fcf05ee7988f445b9a
Comment 12 Martin Flöser 2018-02-01 20:13:03 UTC
Did 5.11 fix the issue?
Comment 13 Christoph Feck 2018-02-22 21:18:55 UTC
If you can provide the information requested in comment #12, please add it.
Comment 14 Emre 2018-02-24 18:58:31 UTC
I can freely move windows now over the taskbar. So I think the issue is resolved. Latest KDE in Arch, I guess it's 5.12.2.
Comment 15 Martin Flöser 2018-02-25 07:23:23 UTC
Setting to fixed as of latest comment
Comment 16 Martin Flöser 2018-03-03 06:34:54 UTC
*** Bug 391279 has been marked as a duplicate of this bug. ***