Bug 228819 - Maximize by dragging to top of the screen should not unmaximize window until it has actually been moved
Summary: Maximize by dragging to top of the screen should not unmaximize window until ...
Status: RESOLVED DUPLICATE of bug 222100
Alias: None
Product: kwin
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Packages Unspecified
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-27 23:56 UTC by Nikola Kovacs
Modified: 2013-03-11 11:42 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.