Bug 371199 - Dragging windows on my left screen causes them to jump down to the bottom
Summary: Dragging windows on my left screen causes them to jump down to the bottom
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: 5.8.2
Platform: Archlinux Linux
: NOR major with 8 votes (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL: https://www.youtube.com/watch?v=7tLKM...
Keywords:
: 370583 372553 372796 373689 374790 376088 377728 379851 380052 381217 384825 384952 402160 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-10-19 03:48 UTC by mitchell
Modified: 2020-09-02 00:32 UTC (History)
22 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.11
mgraesslin: Wayland-
mgraesslin: X11+
mgraesslin: ReviewRequest+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mitchell 2016-10-19 03:48:29 UTC
My install of KDE is from about 5.6 or so.

After installing 5.8, the behaviour you can see in the linked video began. Any time a window on my left screen is grabbed by the titlebar, it jumps straight down to the bottom. When enough of the window is sitting on my right screen, it jumps back onto my cursor as normal. Using the Move command from the right click menu gives the same result. 

I can use the window snapping features (dragging to top and side of screen) normally on both monitors. Even though the window jumps to the bottom of the screen, when my mouse hits the side of the monitor during the drag, it jumps into the correct position.

I can resize on the left screen normally.

I have tried turning off wobbly windows, no change. I'm using the NVIDIA proprietary driver on X.

Support Information: https://paste.kde.org/pel3hg45s
My Nvidia-settings window for my left (problematic) monitor: http://i.imgur.com/7WPdKCB.png

Reproducible: Always

Steps to Reproduce:
1. Have two monitors
2. Drag a window on the left one
3. why?!

Actual Results:  
Window jumps down to the bottom of the screen. About 2-3 pixels of the window remain onscreen, but I can't grab that, only resize.

Expected Results:  
Window stays on the mouse cursor.
Comment 1 Martin Flöser 2016-10-19 05:25:43 UTC
KWin Support Information:
The following information should be used when requesting support on e.g. http://forum.kde.org.
It provides information about the currently running instance, which options are used,
what OpenGL driver and which effects are running.
Please post the information provided underneath this introductory text to a paste bin service
like http://paste.kde.org instead of pasting into support threads.

==========================

Version
=======
KWin version: 5.8.1
Qt Version: 5.7.0
Qt compile version: 5.7.0
XCB compile version: 1.12

Operation Mode: X11 only

Build Options
=============
KWIN_BUILD_DECORATIONS: yes
KWIN_BUILD_TABBOX: yes
KWIN_BUILD_ACTIVITIES: yes
HAVE_INPUT: yes
HAVE_DRM: yes
HAVE_GBM: yes
HAVE_X11_XCB: yes
HAVE_EPOXY_GLX: yes
HAVE_WAYLAND_EGL: yes

X11
===
Vendor: The X.Org Foundation
Vendor Release: 11804000
Protocol Version/Revision: 11/0
SHAPE: yes; Version: 0x11
RANDR: yes; Version: 0x14
DAMAGE: yes; Version: 0x11
Composite: yes; Version: 0x4
RENDER: yes; Version: 0xb
XFIXES: yes; Version: 0x50
SYNC: yes; Version: 0x31
GLX: yes; Version: 0x0

Decoration
==========
Plugin: org.kde.breeze
Theme: 
Blur: 0
onAllDesktopsAvailable: false
alphaChannelSupported: true
closeOnDoubleClickOnMenu: false
decorationButtonsLeft: 0, 2
decorationButtonsRight: 6, 3, 4, 5
borderSize: 3
gridUnit: 10
font: Noto Sans,10,-1,5,50,0,0,0,0,0
smallSpacing: 2
largeSpacing: 10

Options
=======
focusPolicy: 0
nextFocusPrefersMouse: false
clickRaise: true
autoRaise: false
autoRaiseInterval: 0
delayFocusInterval: 0
shadeHover: false
shadeHoverInterval: 250
separateScreenFocus: false
placement: 4
focusPolicyIsReasonable: true
borderSnapZone: 10
windowSnapZone: 10
centerSnapZone: 0
snapOnlyWhenOverlapping: false
rollOverDesktops: true
focusStealingPreventionLevel: 1
legacyFullscreenSupport: false
operationTitlebarDblClick: 5000
operationMaxButtonLeftClick: 5000
operationMaxButtonMiddleClick: 5015
operationMaxButtonRightClick: 5014
commandActiveTitlebar1: 0
commandActiveTitlebar2: 30
commandActiveTitlebar3: 2
commandInactiveTitlebar1: 4
commandInactiveTitlebar2: 30
commandInactiveTitlebar3: 2
commandWindow1: 7
commandWindow2: 8
commandWindow3: 8
commandWindowWheel: 31
commandAll1: 10
commandAll2: 3
commandAll3: 14
keyCmdAllModKey: 16777251
showGeometryTip: true
condensedTitle: false
electricBorderMaximize: true
electricBorderTiling: true
electricBorderCornerRatio: 0.25
borderlessMaximizedWindows: false
killPingTimeout: 5000
hideUtilityWindowsForInactive: true
inactiveTabsSkipTaskbar: false
autogroupSimilarWindows: false
autogroupInForeground: true
compositingMode: 1
useCompositing: true
compositingInitialized: true
hiddenPreviews: 2
glSmoothScale: 2
colorCorrected: false
xrenderSmoothScale: false
maxFpsInterval: 16666666
refreshRate: 0
vBlankTime: 6000000
glStrictBinding: false
glStrictBindingFollowsDriver: true
glCoreProfile: true
glPreferBufferSwap: 0
glPlatformInterface: 1
windowsBlockCompositing: true

Screen Edges
============
desktopSwitching: false
desktopSwitchingMovingClients: false
cursorPushBackDistance: 1x1
timeThreshold: 150
reActivateThreshold: 350
actionTopLeft: 0
actionTop: 0
actionTopRight: 0
actionRight: 0
actionBottomRight: 0
actionBottom: 0
actionBottomLeft: 0
actionLeft: 0

Screens
=======
Multi-Head: no
Active screen follows mouse:  no
Number of Screens: 2

Screen 0:
---------
Name: DVI-I-0
Geometry: 0,0,1920x1080
Refresh Rate: 60

Screen 1:
---------
Name: DVI-D-0
Geometry: 1920,0,1920x1080
Refresh Rate: 60


Compositing
===========
Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 970/PCIe/SSE2
OpenGL version string: 3.1.0 NVIDIA 370.28
OpenGL platform interface: GLX
OpenGL shading language version string: 1.40 NVIDIA via Cg compiler
Driver: NVIDIA
Driver version: 370.28
GPU class: Unknown
OpenGL version: 3.1
GLSL version: 1.40
X server version: 1.18.4
Linux kernel version: 4.7.7
Direct rendering: Requires strict binding: no
GLSL shaders:  yes
Texture NPOT support:  yes
Virtual Machine:  no
OpenGL 2 Shaders are used
Painting blocks for vertical retrace:  no

Loaded Effects:
---------------
zoom
slidingpopups
kwin4_effect_login
wobblywindows
slide
screenshot
kwin4_effect_windowaperture
kwin4_effect_translucency
minimizeanimation
cube
sheet
resize
kwin4_effect_morphingpopups
kwin4_effect_maximize
kwin4_effect_fade
presentwindows
highlightwindow
kwin4_effect_dialogparent
blur
contrast
windowgeometry
startupfeedback
screenedge
kscreen

Currently Active Effects:
-------------------------
blur
contrast

Effect Settings:
----------------
zoom:
zoomFactor: 1.2
mousePointer: 0
mouseTracking: 0
enableFocusTracking: false
followFocus: true
focusDelay: 350
moveFactor: 20
targetZoom: 1

slidingpopups:
fadeInTime: 30
fadeOutTime: 50

kwin4_effect_login:

wobblywindows:
stiffness: 0.06
drag: 0.9
moveFactor: 0.1
xTesselation: 20
yTesselation: 20
minVelocity: 0
maxVelocity: 1000
stopVelocity: 0.5
minAcceleration: 0
maxAcceleration: 1000
stopAcceleration: 0.5
moveEffectEnabled: true
openEffectEnabled: false
closeEffectEnabled: false
moveWobble: true
resizeWobble: true

slide:

screenshot:

kwin4_effect_windowaperture:

kwin4_effect_translucency:

minimizeanimation:

cube:
cubeOpacity: 0.800000011920929
opacityDesktopOnly: false
displayDesktopName: true
reflection: true
rotationDuration: 100
backgroundColor: #000000
capColor: #31363b
paintCaps: true
closeOnMouseRelease: false
zPosition: 100
useForTabBox: false
invertKeys: false
invertMouse: false
capDeformationFactor: 0
useZOrdering: false
texturedCaps: true

sheet:
duration: 100

resize:
textureScale: true
outline: false

kwin4_effect_morphingpopups:

kwin4_effect_maximize:

kwin4_effect_fade:

presentwindows:
layoutMode: 0
showCaptions: true
showIcons: true
doNotCloseWindows: false
ignoreMinimized: false
accuracy: 20
fillGaps: true
fadeDuration: 30
showPanel: false
leftButtonWindow: 1
rightButtonWindow: 2
middleButtonWindow: 0
leftButtonDesktop: 2
middleButtonDesktop: 0
rightButtonDesktop: 0

highlightwindow:

kwin4_effect_dialogparent:

blur:
blurRadius: 12
cacheTexture: true

contrast:

windowgeometry:
handlesMoves: true
handlesResizes: true

startupfeedback:
type: 1

screenedge:

kscreen:
Comment 2 Martin Flöser 2016-10-19 05:27:04 UTC
can you try removing the panel between your screens?
Comment 3 mitchell 2016-10-19 07:22:52 UTC
Whoa, that fixed it! Crazy stuff. Readding the panel causes the problem to reappear.
Comment 4 Martin Flöser 2016-10-19 07:54:41 UTC
Thanks for testing! Now we know where the problem is.
Comment 5 Martin Flöser 2016-11-17 07:04:35 UTC
*** Bug 372553 has been marked as a duplicate of this bug. ***
Comment 6 Martin Flöser 2016-11-23 06:38:34 UTC
*** Bug 372796 has been marked as a duplicate of this bug. ***
Comment 7 abulak 2016-12-13 07:09:27 UTC
Do You have a fix/patch to test? would be glad to test;

(As I understand this is related to recent changes in kwin
(i.e. August 2016: https://blog.martin-graesslin.com/blog/2016/08/panels-on-shared-screen-edges/)
Comment 8 mowalle.dev 2016-12-31 12:36:32 UTC
In addition to what was already described, I want to add that this behaviour occurs on all four screen edges if there is a panel next to another screen/monitor.

As a workaround, I found that dragging a window while pressing the ALT key allows for normal movement.
Comment 9 Martin Flöser 2017-01-09 05:59:41 UTC
*** Bug 374790 has been marked as a duplicate of this bug. ***
Comment 10 Martin Flöser 2017-02-06 18:46:09 UTC
*** Bug 376088 has been marked as a duplicate of this bug. ***
Comment 11 niet.giftig 2017-02-06 18:54:16 UTC
What is necessary to make bug confirmed, assigned, and corrected?
Or is is this bug tracker merely a "please keep quit" place?
Is it useful to report bugs, or is it just a diversion?
Comment 12 Martin Flöser 2017-02-06 20:11:03 UTC
> What is necessary to make bug confirmed, assigned, and corrected?

Confirmed has no meaning on KDE's bug tracker. In KWin we do not use assigned.

I hope to find time for this bug, but I cannot promise anything. In general nagging results in bugs getting way lower priority. Currently we have bugs of higher priority.
Comment 13 paul_arts 2017-02-07 07:59:54 UTC
I confirm this bug. However for me it happens only when primary monitor has vertical panel. My video showing reproducing of this: https://yadi.sk/i/NeByvNm038yuxm

Are there any ideas what causes this behavior? It is quite easy to reproduce this, maybe bug status should be changed to CONFIRMED?
Comment 14 paul_arts 2017-02-07 08:02:57 UTC
(In reply to paul_arts from comment #13)
> Are there any ideas what causes this behavior? It is quite easy to reproduce
> this, maybe bug status should be changed to CONFIRMED?

Sorry, I did not notice previous Martin Gräßlin's comment about confirmed status and bug priority. Anyway, please note that this bug makes KDE unusable on 2 widescreen monitors.
Comment 15 supaiku 2017-03-27 16:53:30 UTC
From my observation it does not happen when the window uses client side decoration. I tested it with Chromium with and without client-side decoration. When the Breeze decoration is enabled I experience the bug as reported. But when it's off I don't experience the issue anymore. So I tested it with Lollypop (GTK+ music player) and I can drag it without any problems as well.
Comment 16 Andreas Wanka 2017-05-05 18:36:32 UTC
I switched to cinnamon because of this bug. However, there, this bug seems to manifest itself by dropdowns (like menues) of kde apps not working in one screen (primary left for me), but working in the other.
Comment 17 Christoph Feck 2017-05-15 22:37:15 UTC
*** Bug 379851 has been marked as a duplicate of this bug. ***
Comment 18 Cristiano Guadagnino 2017-05-23 17:14:40 UTC
I'm affected by the bug too.

I want to also add that this makes yakuake unusable on the second monitor.
That is, when Yakuake is configured to pop-up on whichever monitor the mouse is, it will NOT pop-up if the mouse is on the second monitor.

I know multi-monitor setups are probably not that common, but this is a very bad bug for anyone wishing to use KDE in such a setup, and it gives out the message that KDE is badly broken. 
Not many people will reach this bug-report before dumping KDE for another DE. And there's a good chance they will dump it anyway, even if this bug is rated as "not very important".
Comment 19 chris 2017-05-31 08:40:28 UTC
(In reply to Cristiano Guadagnino from comment #18)
> I'm affected by the bug too.
> 
> I want to also add that this makes yakuake unusable on the second monitor.
> That is, when Yakuake is configured to pop-up on whichever monitor the mouse
> is, it will NOT pop-up if the mouse is on the second monitor.
> 
> I know multi-monitor setups are probably not that common, but this is a very
> bad bug for anyone wishing to use KDE in such a setup, and it gives out the
> message that KDE is badly broken. 
> Not many people will reach this bug-report before dumping KDE for another
> DE. And there's a good chance they will dump it anyway, even if this bug is
> rated as "not very important".

I agree as I am in exactly the same position.

I've always liked the look and functionality of Plasma but never given it enough time to make the switch, so I thought I'd make some time. An hour into setting things up I came across this bug and spent some time researching and troubleshooting, finally coming across this page. As this was reported 7 months ago and still not confirmed, I don't hold out much hope of things changing soon and unfortunately KDE is unusable (for me at least) without this being fixed. So i'm afraid I'm back off to another DE. 

I'll keep an eye on this and perhaps I'll look at having another go with KDE once it's fixed.
Comment 20 Christoph Feck 2017-06-06 18:29:11 UTC
*** Bug 380052 has been marked as a duplicate of this bug. ***
Comment 21 Daniel Lichtenberger 2017-06-11 10:56:07 UTC
AFAIUI the problematic code is in AbstractClient::handleMoveResize (geometry.cpp) of kwin. As described in the blog post mentioned above, putting a panel in the middle of the screen covers the entire left screen internally. The code in AbstractClient doesn't seem to handle this: the entire left screen is removed from the "available" area for moving, which causes issues down the line.

For example, with my setup (1280x1024 left-of 1680x1050), a panel on the left-hand side of the right monitor has a "strut" of (0,0 1330x1049). Removing this area from the available area will cause issues. Setting the left edge of the strut to 1280 (the width of the left monitor) seemed to fix the issue for me but probably isn't a solution if this scenario is essentially not covered by the spec.

Pressing "Alt" while moving triggers an unrestricted move mode that just uses the entire (virtual) screen for moving and ignores the panel altogether, thus avoiding the issue.
Comment 22 Christoph Feck 2017-06-19 14:28:42 UTC
*** Bug 381217 has been marked as a duplicate of this bug. ***
Comment 23 Martin Flöser 2017-07-05 15:04:00 UTC
Daniel, thanks for your investigation. Based on that I did quite some additional investigation. I noticed that it is not trivial to fix. Everything I tried so far did not solve the problem properly and I think a larger refactoring of the code is needed. The "root" problem is that struts are constructed from the edge of the overall screen layout. So the strut of a panel in between restricts on all screens.

This code was so problematic that the Wayland implementation never got implemented and only has a TODO. Which explains why I couldn't reproduce this issue on Wayland. But on the other hand we also need to make it work on Wayland. Given that a larger refactoring is required. Luckily it's well contained and given the investigation so far it is possible.

But due to the fact that I think it will require a larger refactoring I doubt that this can be provided as a bug fix.
Comment 24 Martin Flöser 2017-07-08 06:51:30 UTC
Possible patch at https://phabricator.kde.org/D6562
Comment 25 Daniel Lichtenberger 2017-07-08 14:34:58 UTC
Hi Martin,

thanks for the patch! This does seem to solve the issue for me.
Comment 26 Martin Flöser 2017-07-11 15:53:02 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 370510
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 27 Martin Flöser 2017-07-22 16:13:51 UTC
*** Bug 377728 has been marked as a duplicate of this bug. ***
Comment 28 Martin Flöser 2017-09-10 14:33:28 UTC
*** Bug 373689 has been marked as a duplicate of this bug. ***
Comment 29 Martin Flöser 2017-09-19 19:57:20 UTC
*** Bug 384825 has been marked as a duplicate of this bug. ***
Comment 30 Christoph Feck 2017-10-12 19:40:52 UTC
*** Bug 370583 has been marked as a duplicate of this bug. ***
Comment 31 Christoph Feck 2017-10-12 20:31:12 UTC
*** Bug 384952 has been marked as a duplicate of this bug. ***
Comment 32 Cristiano Guadagnino 2017-10-12 22:26:20 UTC
Hours ago I received an update to openSUSE Tumbleweed, so that now I'm on plasma 5.11. 
I can confirm that (at last!) the bug is fixed and I can move windows on the second monitor without problems.
However the problem with Yakuake still remains: when configured so that its window appears on the monitor where the mouse cursor resides, it turns out that it really won't appear on the left monitor. That is: if I press the hotkey that is supposed to show Yakuake's window, it will do nothing if the mouse cursor is on the left screen.
This makes me think that the bug is still not completely solved.
Comment 33 Cristiano Guadagnino 2018-04-24 08:04:10 UTC
I can confirm that Yakuake's behavior (i.e. it does not appear on the left monitor) is a direct consequence of this bug, because if I move my panel to the right side of the right monitor (instead of being "between the monitors"), Yakuake behaves correctly.
I tried to file a bug for Yakuake too, to see if it is possible to implement a workaround in Yakuake's code, but it actually makes more sense to fix the problem here.
Comment 34 Martin Flöser 2018-04-24 14:49:29 UTC
I do not understand why this bug was reopened. The issue described in this bug report is fixed. Please do not just reopen bugs for other issues
Comment 35 Cristiano Guadagnino 2018-04-24 16:18:03 UTC
Martin, how can you say the issue is solved if there's a program that shows the  same behavior with the exact same cause?
The only difference here is that Yakuake cannot be dragged from one monitor to the other, due to the way Yakuake is shown on the screen, but it remains a fact that when Yakuake tries to appear on the second screen it's position is not what it should be resulting in an invisible window.
I am refraining from reopening the bug, for now. Should I open a new bug for this? It seems weird and counterproductive to me, because the main cause of the buggy behavior is the same so reading it in context would give a jump-start to anyone trying to fix the bug.
Comment 36 Christoph Feck 2019-01-09 05:51:47 UTC
*** Bug 402160 has been marked as a duplicate of this bug. ***