Closed Bug 1116569 Opened 5 years ago Closed 5 years ago

Consider reducing touch slop when starting a drag


(Firefox OS Graveyard :: General, defect)

Gonk (Firefox OS)
Not set


(firefox40 fixed)

2.2 S10 (17apr)
Tracking Status
firefox40 --- fixed


(Reporter: kats, Assigned: kats)




(1 file)

Quoted from!topic/

- The default touch slop is too large, making the homescreen (for example) feel "spongy" and unresponsive. Example, touch down and drag, and see how far the finger is from the point it touched.
- I fixed this by setting profiledir/prefs.js "apz.touch_start_tolerance" = "0.1" (default is about 0.2), and did a hard reset. Feels *much* better! 

I don't believe that the value of this pref was ever really tuned by UX, so it might be something worth adjusting.
 Gordon, any thoughts?
Flags: needinfo?(gbrander)
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → All
Hi Kartikaya Gupta,

   Forgive me, but is "apz.touch_start_tolerance" = "0.1" related to drag smoothly?

   Pull down the utility tray, is not very smooth, not timely. I want to optimize it
   Thanks a lot
Flags: needinfo?(bugmail.mozilla)
It affects how far you have to move before panning takes effect. However it does not affect dragging down the utility tray, because that is not handled by the APZ panning code. That is done using touch listeners in gaia as far as I'm aware, so this would have no impact on that.
Flags: needinfo?(bugmail.mozilla)
Huh, didn't know this pref existed. The comment makes it sound like there is no downside to reducing the slop. However, I'm guessing we have a pref because this affects some other aspect of panning.

What are the implications of reducing this value?
Flags: needinfo?(gbrander)
(needsinfo :kats)
Flags: needinfo?(bugmail.mozilla)
Reducing the slop too much means that when the user taps, it is more likely to be interpreted as a pan, because in most taps the finger moves slightly between touchdown and touchup. This can make it frustrating because attempting to tap will move the page instead.
Flags: needinfo?(bugmail.mozilla)
That freaks me out. I recall we used to have a lot of false positives there. I'll loop in Francis for his take, but from my perspective I think we should leave this be unless we have someone spend a lot of time tuning it.
Flags: needinfo?(fdjabri)
I agree with Gordon we should be very careful about reducing the slop if it might impact tap performance. Could someone let me know how I can adjust settings and test this out?
Flags: needinfo?(fdjabri)
(In reply to Francis Djabri [:djabber] from comment #9)
> I agree with Gordon we should be very careful about reducing the slop if it
> might impact tap performance. Could someone let me know how I can adjust
> settings and test this out?

Run '' in the b2g root directory, and add a line of the form

  user_pref("apz.touch_start_tolerance", "0.2");

replacing "0.2" with the value you'd like to test.
Please let us know if you've tried this out and if anything should be changed or if we should just wontfix this bug.
Flags: needinfo?(fdjabri)
Hi, I've finally been able to try this (thanks Botond!). I haven't noticed any bad effects on tap performance - even sloppy taps while on the move seem to be recognized correctly. I think it does help swipe responsiveness. I've noticed previously, for example, in task manager that many swipes would be interpreted as taps. Changing this setting seems to help with that and makes swiping feel a little more responsive and secure. So I'd be happy going ahead with this change.
Flags: needinfo?(fdjabri)
Sorry for dropping the ball here - Francis, do you remember what value you tried out and liked? Was it 0.2 or something else?
Flags: needinfo?(fdjabri)
I changed the setting to 0.1, as you recommended in the description.
Flags: needinfo?(fdjabri)
Attached patch PatchSplinter Review
Assignee: nobody → bugmail.mozilla
Attachment #8588558 - Flags: review?(botond)
Attachment #8588558 - Flags: review?(botond) → review+
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S10 (17apr)
See Also: → 1231229
You need to log in before you can comment on or make changes to this bug.