Bug 357450

Summary: Double click on the titlebar is not a standalone event
Product: [Plasma] kwin Reporter: Ionut Ciocirlan <ionut.ciocirlan>
Component: generalAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: alex, vkrevs
Priority: NOR Flags: thomas.luebking: ReviewRequest+
Version First Reported In: 5.4.3   
Target Milestone: ---   
Platform: Debian unstable   
OS: Linux   
URL: https://git.reviewboard.kde.org/r/126631/
Latest Commit: Version Fixed In: 5.6
Sentry Crash Report:

Description Ionut Ciocirlan 2016-01-02 22:44:09 UTC
Double clicking the titlebar is "leaky": any click that comes short enough after a previous one is considered to be a double click, with no isolation between double clicks.

Reproducible: Always

Steps to Reproduce:
1. Set the double-click titlebar action to maximise;
2. Drag a window by its titlebar to the very top (but don't let it maximise);
3. Double click the titlebar to maximise, pause a little, don't move the mouse;
4. Triple click;
5. Keep clicking.

Actual Results:  
Every single click starting with the 3rd un/re-maximises the window.

Expected Results:  
Only double clicks should do it.
Comment 1 Thomas Lübking 2016-01-04 17:05:08 UTC
@Martin, why is the timer started on release and checked on press?
Afaiu mouseDoubleClickInterval(), it implies a full cycle, ie. you'll have to press (or rather release?) twice within this time to trigger a doubleclick action (resp. all singleclick actions are delayed by this time)

So a press would start on an invalid timer and invalidate (and conditionally start) on a valid timer.
Otherwise we'll have to carry the condition between press and release, but for now I wonder why they're split at all.

Comparing eg. dolphin w/ enabled doubleclick, I can press, hoooooold, press, hooooold, ... w/o triggering something, ie. the time between release and press doesn't matter, but press, release, press, already to late for hooooold... ;-)
Comment 2 Martin Flöser 2016-01-05 07:44:17 UTC
I don't remember why I did it that way, but I took the code from somewhere else. Maybe it interfered with press/move?
Comment 3 Thomas Lübking 2016-01-05 10:51:45 UTC
The release handles the deco event handling case, still required, but no point in starting the timer there.
Comment 4 Thomas Lübking 2016-01-18 21:37:49 UTC
Git commit ed1d32288b50647469fb0e000f21b849e286ca36 by Thomas Lübking.
Committed on 18/01/2016 at 21:34.
Pushed by luebking into branch 'master'.

move doubleclick logic into press event

alignes w/ systemwide behavior and allows elegant fix of
FIXED-IN: 5.6
REVIEW: 126631

M  +18   -8    abstract_client.cpp
M  +1    -0    abstract_client.h
M  +2    -2    events.cpp

http://commits.kde.org/kwin/ed1d32288b50647469fb0e000f21b849e286ca36
Comment 5 Thomas Lübking 2016-01-26 09:16:58 UTC
*** Bug 358566 has been marked as a duplicate of this bug. ***