[MASTER] Trackpad behavior change causes tap-and-drag to lock

Bug #934770 reported by Doug McMahon on 2012-02-18
110
This bug affects 16 people
Affects Status Importance Assigned to Milestone
xserver-xorg-input-synaptics (Ubuntu)
High
Chase Douglas

Bug Description

Since xserver-xorg-input-synaptics 1.5.0+git20120210-0ubuntu2, tap-and-drag locking has been enabled by default. This is a behavior change. When a tap-and-drag is started, it will continue until a tap ends it (effectively depressing the left mouse button). The change is an effort to provide an alternative click-and-drag method for clickpads, where dragging farther than the size of the trackpad is not possible.

This bug is for collating feedback. If the change is adversely affecting you, please note it by clicking the green link at the top of this page "This bug affects x people. Does this bug affect you?" Please do not add extra comments unless absolutely necessary.

[Workaround]
At least here this is what returns my touchpad to being useful & prevents ALL the unintended nonsense from occurring

synclient LockedDrags=0 TapButton1=1 TapButton2=3 TapButton3=2

[Original bug description]
Not sure if proper source, wasn't the utouch libs

Recently here & with others the left click 'select' has been 'randomly' getting stuck on, causing the cursor to select everything in it's path & otherwise be unresponsive, ie. nothing can be clicked on.

At least here the effect lasts for about 20 -30 sec's, when it happens if stopping all activity the cursor & control return in that time frame

It is also seen on occasion as a 'stuck' grab, same deal, nothing can be done till something releases. Additionally I've a few instances where suddenly the left click is non-functional, again control returns within 20 -30 sec's

With a little practice have been able to cause this to happen within a few attempts, basically moving the cursor with left button depressed (highlight) combined with a small tap.
So will attach 2 video's with short descriptions

Disabling 'tap to click' has prevented this from happening inadvertently over a day long test

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libutouch-geis1 2.2.5-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-16.25-generic-pae 3.2.6
Uname: Linux 3.2.0-16-generic-pae i686
ApportVersion: 1.91-0ubuntu1
Architecture: i386
Date: Sat Feb 18 01:15:48 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha i386 (20120216)
MachineType: Dell Inc. XPS M1330
MtDevices: No capable devices found...
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-16-generic-pae root=UUID=e5d89c99-ea87-4066-adde-b104f1d05dd6 ro quiet splash vt.handoff=7
SourcePackage: utouch-geis
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/26/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A15
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA15:bd12/26/2008:svnDellInc.:pnXPSM1330:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: XPS M1330
dmi.sys.vendor: Dell Inc.

Doug McMahon (mc3man) wrote :
Doug McMahon (mc3man) wrote :

This was simply on the Desktop, once the left click 'stuck' I've released the left mouse button & am simply just moving the cursor with the touchpad. The cursor will not release & nothing else can be clicked on.
After the short stop control is returned

Doug McMahon (mc3man) wrote :

This is a file opened in gedit, took a couple of attempts to initiate
Once the cursor stuck on left click the all cursor movement just highlighted text even when leaving gedit.
Nothing else on the Desktop could be clicked on, launcher, Desktop items, panel items.
Again after a short period of inactivity control did return

Doug McMahon (mc3man) on 2012-02-18
affects: utouch-geis (Ubuntu) → xserver-xorg-input-synaptics (Ubuntu)
description: updated
Chase Douglas (chasedouglas) wrote :

Hi Doug,

What version of xserver-xorg-input-synaptics do you have?

Thanks!

Changed in xserver-xorg-input-synaptics (Ubuntu):
importance: Undecided → High
status: New → Incomplete
Doug McMahon (mc3man) wrote :

Chase - I have this version installed
1.5.0+git20120210-0ubuntu2

Am actually at a bit of a loss as to possible package, initially thought the utouch libs but after downgrading both the geis & frame1 to 2 versions back was able to eventually cause

Atm have everything up to date & am running with 'tap to click' disabled in g-c-c. So with it disabled I obviously can't intentionally cause this to happen, figured I' d run for a few days & see if it happened 'naturally', so far today it hasn't

If it was just me I'd chalk up to hardware corner case but a number of users have complained of this over the past week.
If I try in 11.10 to cause this it isn't possible
See in both unity 3d & unity-2d, haven't tried other sessions

Doug McMahon (mc3man) wrote :

Additional to note - I was curious if the g-c-c 'tap to click' was listed in synclient -l so I re-enabled in g-c-c, ran it in a terminal & will simply scrolling the list the cursor got caught. After a short wait it released..

Doug McMahon (mc3man) wrote :

Sorry to spam this - starting to think a mouse "click" has nothing to do with this

By default TapAndDragGesture is set to 1 which here allows 2 & 3 taps to register (2 tap to open, 3 tap to highlight

So what's happening is a quick 2 tap & cursor move is 'grabbing' , this lasts till I stop activity & wait 5 sec's.

If I set TapAndDragGesture to 0 then I'm only getting a single tap registered & I believe this issue can't occur

So if TapAndDragGesture=1 is intended to allow 2/3 tap then possibly this can be considered user error & not a bug?

Doug McMahon (mc3man) on 2012-02-19
Changed in xserver-xorg-input-synaptics (Ubuntu):
status: Incomplete → New
Pat McGowan (pat-mcgowan) wrote :

This sounds like the behavior expected now that Synaptics locked drags is enabled per https://lists.ubuntu.com/archives/ubuntu-desktop/2012-February/003694.html

The user must add a final tap to end the drag/selection, or wait for the timeout

Sebastien Bacher (seb128) wrote :

That seems the same issue than bug #934770

the change was discussed described by Chase on
https://lists.ubuntu.com/archives/ubuntu-desktop/2012-February/003694.html

"* When the user checks "Enable mouse clicks with touchpad", I believe
the "Synaptics Locked Drags" setting should be true.
...
If it's not entirely clear what the change is, try setting the property
and playing with it. Enabling the property resolves the problem of
trying to drag farther than your touchpad is wide or tall."

Reassigning to xserver-xorg-input-synaptics

Sebastien Bacher (seb128) wrote :

sorry I commented on the wrong bug, the previous comment was for bug #934184

Doug McMahon (mc3man) wrote :

The locked drag is accounting for some of this & yes, users can exit with a single tap when dragging something.
 (though in the past I believe most users of the typical single finger touchpads would just simply hold button one for extended drags

What it, lthe ocked drag being enabled, isn't accounting for is the constant 'locked highlighting' in browsers & text files ala the 2nd video
. In this case a double tap, (2 taps, 1 finger) is needed to exit or wait for the time out
At least here on a small touchpad, 1.5X2 inches, this is occurring constantly. Is it now the position that I & many other users have to either put up with it, 2 tap out, & or retrain our use of touchpads? Again on small touchpads an inadvertent single finger 2 tap is common

Additionally this change or changes are now causing these periods of loss of any left click function, in these cases a wait out is needed. I've not yet found how to reproduce that other then it's definitely caused by an inadvertent 2 or maybe 3 tap, single finger. (with 2 & 3 single finger tap disabled here it has never re-occured

I'm not sure to whose benefit these changes are being made for, likely not the majority at this point & it would seem better to provide them thru non -default options.
I guarantee if left as is the complaints & user confusion will certainly increase

Sebastien Bacher (seb128) wrote :

> What it, lthe ocked drag being enabled, isn't accounting for is the constant 'locked highlighting' in browsers & text files ala the 2nd video

why not? if you click and dnd you select which seems to be what you describe?

Chase Douglas (chasedouglas) wrote :

I can verify what Sebastien has written. I made the change to synaptics to default to locked tap-and-drag. It was a requested feature by people with clickpad devices because it was very difficult to click and drag before.

I am monitoring feedback from users about this and other changes. If many people find it to be a problem, we can consider reverting it. I'm merely trying to weigh the benefits and advantages.

I hope to merge better clickpad support late this week or early next through a feature freeze exception. If that lands, we can probably revert this change as clickpad users will have a more natural option for clicking and dragging beyond the size of the trackpad.

Changed in xserver-xorg-input-synaptics (Ubuntu):
assignee: nobody → Chase Douglas (chasedouglas)
status: New → Triaged
summary: - Inadvertant mouse movement & click is causing cursor to stick on left
- click
+ Trackpad behavior change causes tap-and-drag to lock
description: updated

On 02/21/2012 02:30 PM, Sebastien Bacher wrote:
>> What it, lthe ocked drag being enabled, isn't accounting for is the
> constant 'locked highlighting' in browsers& text files ala the 2nd
> video
>
> why not? if you click and dnd you select which seems to be what you
> describe?
>
In the context of if I disable LockedDrags it still happens, previous
behavior was that a 2 tap with movement would highlight only to the
extent of the movement, then it released
Now it never releases until an inactivity timeout or a new 2 tap

Additionally this is often not the result of intentionally wanting to
highlight anything, it just keeps happening inadvertently thru normal
touchpad use, probably more likely on very small touchpads

And then there is the also newly introduced loss of left click
altogether for a time based period, again this is from inadvertent
action(s), not sure what yet

(noting that when I say 2 tap I mean 2 single finger taps

> It was a requested feature by people with clickpad devices
> because it was very difficult to click and drag before.
>
> I am monitoring feedback from users about this and other
> changes. If many people find it to be a problem, we can
> consider reverting it. I'm merely trying to weigh the benefits
> and advantages.

IIRC it used to be that when selecting, a release of pressure on the touchpad stopped the selection - so the addition of a positive action to stop selecting is, at least to me, a benefit.

However it is the unwanted selection of text that is a problem. Before this patch, a double tap and movement was required to begin selecting text - now it seems a single tap triggers selection. Programming in Geany using the touchpad to move around code is very trying.

Pat McGowan (pat-mcgowan) wrote :

synclient LockedDrags=0 restores the previous behavior but this of course resets each boot. Previous behavior being the selection ends when the finger is raised.

I do not see selections start in a single tap when LockedDrags is enabled. A double tap is required to begin, and a single tap or timeout to release.

I should probably also note that, at least on my laptop, dragging things isn't the only activity adversely affected by this. Trying to hold down spinbox buttons, for example, causes them to continue to increase/decrease at a high rate until an extra tap is used to stop it, which is slower than just releasing the trackpad. So at least in the case of spinboxes, this change makes them much more difficult to use when trying to quickly spin up/down to a certain value, especially at times when the extra needed click occasionally doesn't register and you end up rocketing all the way to the maximum/minimum allowed value.

Doug McMahon (mc3man) wrote :

This bug wasn't initially just about locked drags nor intended user actions. It was and still should be considering the poor behavior that the current settings will produce for common users like myself who have a basic synaptics touchpad

In that case there are continual unintended highlighting, grabbing of text or files and temp loss of the left click. Myself & others like me shouldn't have to be figuring out the synclient parameters & running commands to gain the expected & full use of our touchpads.
So there should be a visible option to return to that, in System Settings, a Start up option, whatever.

At least here this is what returns my touchpad to being useful & prevents ALL the unintended nonsense from occurring

synclient LockedDrags=0 TapButton1=1 TapButton2=3 TapButton3=2

Bryce Harrington (bryce) wrote :

@Chase, unless you plan to revert this soon, please make sure this is mentioned in the beta1 release notes.

summary: - Trackpad behavior change causes tap-and-drag to lock
+ [MASTER] Trackpad behavior change causes tap-and-drag to lock
description: updated
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-input-synaptics - 1.5.99~git20120223-0ubuntu1

---------------
xserver-xorg-input-synaptics (1.5.99~git20120223-0ubuntu1) precise; urgency=low

  * Update to latest code in git (0a2fd56)
    - Only includes bug fixes
  * Drop temporary patches that have been merged upstream:
    - 129_tmp_pointer_drift.patch
    - 130_tmp_touch_count_fix.patch
  * Revert tap-and-drag locking default change (LP: #934770)
    - Drop 127_default_drag_lock.patch
  * Add ClickPad support (LP: #932947)
    - Add 129_clickpad.patch
 -- Chase Douglas <email address hidden> Thu, 23 Feb 2012 11:54:37 -0800

Changed in xserver-xorg-input-synaptics (Ubuntu):
status: Triaged → Fix Released
Chase Douglas (chasedouglas) wrote :

Since the feature freeze exception was granted for adding clickpad support, I decided to revert the change in behavior. ClickPad devices now have a better way of performing a press-and-drag, so the need for locked drags has been alleviated.

Marcelo (mmtsales) wrote :

I'm experiencing several erratic behaviors with the mouse in 12.04 64 bits. Don't know if they are related to this bug report... Should I file another report? Some examples:
1. In libreoffice Calc, if I hover the mouse over the zoom control bar in the bottom right corner of Calc's window, the mouse grabs the zoom control by itself. If I move the mouse left and right, without ever touching its buttons, it drags the zoom control left and right.
2. In libreoffice Calc, if I left-click a tab other than the currently selected one, the new tab is selected as expected, but the mouse behaves as if the clicked button stuck. When I move the mouse after selecting another tab, the mouse cursor changes to the arrow with the little rectangle, as if it was dragging a cell.
3. In Chromium, if I right-click a link and left-click "Open link in new tab", the mouse behaves as if the left-click stuck. When I move the mouse after selecting the new tab, the mouse cursor changes to the little hand grabbing a sheet, as if I was moving the link.
4. In Chromium, if I middle-click a link to open it in a new tab and then left-click the newly opened tab, the mouse cursor changes to the cross with arrowed points (the move window cursor) and the window is restored, as if I started to drag it and let it go right after.

Are these problems related to this bug or should I file another? I'm currently running Kubuntu 12.04 64 bits fully updated.

dum (dummyxl) wrote :

it is not the same, this have to do with drag and hold on window borders etc. There reversed the setting and the behavior no longer occurs.

Please file another report.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions