After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 723659 - touchpad: please do not interpret tap and click as double-click
touchpad: please do not interpret tap and click as double-click
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Class: GdkDevice
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Carlos Garnacho
Depends on:
Blocks:
 
 
Reported: 2014-02-05 09:49 UTC by Fabian Greffrath
Modified: 2016-02-24 01:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GtkGestureMultiPress: reset multi-press sequence if the source device changes (2.38 KB, patch)
2016-02-22 21:45 UTC, Carlos Garnacho
committed Details | Review
gdk: Avoid 2/3BUTTON event generation if the source device changes (3.12 KB, patch)
2016-02-22 21:45 UTC, Carlos Garnacho
committed Details | Review

Description Fabian Greffrath 2014-02-05 09:49:10 UTC
Hi,

it happens sometimes that I move the "mouse" cursor with my touchpad to place it e.g. on some field and then press the left touchpad button to actualy "click" on that field. However, it may happen that I release my finger from the touchpad in a manner that GTK+ interprets as a tap (maybe because of some minimal tremor of my hand) and thus interprets the actual button press as the second click, both of which form a double-click. There are some fields, e.g. in the mail list in Evolution, which react completely different on a single and a double click, e.g. opening a mail in a separate window in stead of merely selecting it. Thus, this often leads to undesired behaviour.

TL;DR: Please do not interpret a tap on the touchpad and a subsequent button press a a double-click. For a double-click I would either double-tap on the touchpad or double-press the button.

Thanks,

 - Fabian
Comment 1 Carlos Garnacho 2014-02-06 12:09:53 UTC
Thanks for the bug report, I agree double/triple click should stick to a same source device when initiated. Although there are a few places where such clicks are recognized/generated in place, rather than trusting GDK's.

One of those common places is list widgets, for example treeview does its own detection here to ensure all clicks happen on a single row, I would assume evolution's ETable does something similar, so another bug should reported to that product, perhaps mentioning this one.

As for the solution itself, it's easy enough, just check gdk_event_get_source_device() and forget previous clicks if it did change, I'll make a few patches for GTK+
Comment 2 Matthias Clasen 2016-01-10 16:30:06 UTC
Carlos, did those patches ever appear / land ?
Comment 3 Matthias Clasen 2016-02-21 05:36:50 UTC
ping - Carlos ?
Comment 4 Carlos Garnacho 2016-02-22 21:45:24 UTC
Created attachment 321900 [details] [review]
GtkGestureMultiPress: reset multi-press sequence if the source device changes

This prevents multipress sequences to possibly come from different mice.
Now the accumulated number of presses will be reset if the device changes
in the mean time.
Comment 5 Carlos Garnacho 2016-02-22 21:45:29 UTC
Created attachment 321901 [details] [review]
gdk: Avoid 2/3BUTTON event generation if the source device changes

Remember the last source device we're generating multiple clicks for,
just so we can bail out if the device changed. That will just reset
the counting.
Comment 6 Matthias Clasen 2016-02-24 01:40:18 UTC
Attachment 321900 [details] pushed as 3d70051 - GtkGestureMultiPress: reset multi-press sequence if the source device changes
Attachment 321901 [details] pushed as 4ff3d5b - gdk: Avoid 2/3BUTTON event generation if the source device changes