Bug 228819

Summary:	Maximize by dragging to top of the screen should not unmaximize window until it has actually been moved
Product:	[Plasma] kwin	Reporter:	Nikola Kovacs <nx.devnull>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	tesfabpel
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Ubuntu
OS:	Unspecified
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Nikola Kovacs 2010-02-27 23:56:47 UTC

Version:            (using KDE 4.4.0)
Installed from:    Ubuntu Packages

When "Maximize by dragging windows to the top of the screen" is enabled in Screen Edges, maximized windows are unmaximized as soon as they enter move mode. In the case of KWin windows, you can just hold down the mouse button on the title bar for a few seconds for this to happen (without moving the mouse). However, Google Chrome (which uses a custom titlebar and window borders) enters move mode as soon as you left click on its title bar, which means it is immediately unmaximized, even if you just wanted to switch to it, or you missed the new tab button etc.

I think KWin should not unmaximize windows using this gesture until they have actually been moved. Compare to Compiz: it doesn't snap off maximized windows until you have moved the mouse cursor quite a lot.

See also bug 228815

Comment 1 Martin Flöser 2010-02-28 10:22:20 UTC

It is intended that the window unmaximizes as soon as the move mode is entered. KWin uses a drag delay (which should be changed to a pixel delay) for entering the moving mode. The fact that Chrome uses an own decoration is a chrome bug. It is not the task of the window manager to fix broken applications. If Chrome enters the move mode immediately it is inconsistent to the behaviour of all other windows and that is definately an application bug (just another case why it is the wrong decision to paint own decorations). So you should report this issue to the Chrome developers.

Anything else mentioned in this report is the same as what you said in #228815, therefore I mark as duplicate.

*** This bug has been marked as a duplicate of bug 228815 ***

Comment 2 Nikola Kovacs 2010-02-28 10:57:27 UTC

Chrome is consistent with compiz (and probably metacity), so I doubt they'll want to change that. Yes, it's a bad thing that it draws its own decorations (and the tab strip still acts as a title bar when that is disabled, and chromium developers are reluctant to change that, see http://code.google.com/p/chromium/issues/detail?id=36582), but I think the window shouldn't be unmaximized by just holding your mouse button on the title bar regardless of the Chrome bug.

Anyway, this isn't a duplicate of bug 228815, that's an entirely different issue (the window position isn't updated correctly).

*** This bug has been marked as a duplicate of bug 222100 ***

Comment 3 Nikola Kovacs 2010-02-28 11:05:03 UTC

I've reported a Chrome bug: http://code.google.com/p/chromium/issues/detail?id=37013

Comment 4 tesfabpel 2013-03-11 11:00:42 UTC

It seems to affect even Steam... so it should not be only Chrome-related...

Comment 5 Thomas Lübking 2013-03-11 11:42:49 UTC

a) this bug is a duplicate
b) it will affect *any* client which ships its own deco and move logics

this is one of the reasons why all kwin developers (that i'm aware of) think that "csd" is an utterly stupid idea - the client will trigger the moversize mode whenever it feels like. complain there.
delaying the client request in the wm is no option since we cannot know whether the client itself reasonably delayed the request.