List scrolling - swiping a small distance has no inertia

RESOLVED FIXED in Firefox 21


7 years ago
6 years ago


(Reporter: pla, Assigned: vingtetun)


B2G C4 (2jan on)
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:-, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18+ fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)


(Whiteboard: interaction, UX-P1, BerlinWW)


(2 attachments)



7 years ago
Go into Settings and scroll up and down.  If you use a large enough or fast enough swipe motion, there is inertia in the scrolling.  If you use a small or slow swipe, there is no inertia.  This creates lowers the overall quality of the scrolling experience and makes it feel difficult & clunky.

Solution: Add a small amount of inertia for smaller (ie. for a small displacement) or slower (ie. below the threshold speed where inertia doesn't kick in) swipe motions.

Tested on: otoro_2012-10-22_ics_us
Priority: -- → P3
Component: Gaia → Gaia::Settings
Component: Gaia::Settings → Gaia::System

Comment 1

7 years ago
Rewriting with perf/ux-trust bug template.


What makes it feel slow/broken?

When I'm swiping through a list, such as in the Settings app, the scrolling motion will often 'catch' and just stop, instead of moving in the direction of my swipe, with inertia.  I've noticed this only happens when I swipe a small distance (about the distance of one list item ~60 pixels).

Did it prevent you from doing what you wanted? Why?

It slows me down from finding the item I want in the list, and overall just feels broken.  It's a frustrating feeling.

How does this make you feel?

[ ]  :)  I feel happy about it
[ ]  :|  Meh
[X]  :(  I'm upset
[ ] >:O  I'm angry

Device: Unagi, Nov. 22 Nightly.

Details: (technical factors, FPS, app startup time, ms elapsed, etc)

Bonus: can you attach a video of the problem?
Summary: [transition] [perf] Index Lists Scrolling - Swiping a Small Distance Has No Inertia → [Gaia::System][ux-trust] Index Lists Scrolling - Swiping a Small Distance Has No Inertia
Priority: P3 → P1


7 years ago
Summary: [Gaia::System][ux-trust] Index Lists Scrolling - Swiping a Small Distance Has No Inertia → [Gaia::System] Index Lists Scrolling - Swiping a Small Distance Has No Inertia

Comment 2

7 years ago

Comment 3

7 years ago
Nominating for basecamp-block+.

This inertia problem makes scrolling through a list feel completely broken.
blocking-basecamp: --- → ?
blocking-basecamp: ? → +
Priority: P1 → P3
from EU/Taipei gaia triage, change it to BB+ and make it P3 with BB+
While not fantastic, I do not think this feels *broken*. Scrolling still works, and this only occurs with very small scroll gestures. Inertia works fine otherwise.

I do not think this is something we'd hold the entire release to fix. Re-nominating for broader input.
blocking-basecamp: + → ?
blocking-basecamp: ? → -


7 years ago
blocking-basecamp: - → ?
Keywords: perf, polish
Whiteboard: visual design → interaction

Comment 6

7 years ago
Renoming for bb+.

Dietrich, you're correct in saying that scrolling technically works.  But it's such a fundamental activity throughout the OS, why would you release something with a noticeable resistence to user interaction?  Scrolling is a top 5 item for me, and this bug, when fixed in conjuntion with bug 804315 and the overall system improvements will significantly improve the experience.  If you don't fix this bug, scrolling will always feel unnecessarily resistant.

It may not be completely broken, but it is broken.  Please don't ignore this.

If I was head chef, I would not let this out of my kitchen.  It's poor quality, plain and simple. :/


7 years ago
Blocks: 814751
No longer blocks: c&c


7 years ago
Whiteboard: interaction → interaction, UX-P1
Agreed. Attention to touch input details like these are essential to creating an impression of quality and enjoyment. Our current implementation is currently well below even early-version Android. Ideally we could improve this system wide.

Chris and Vivien, would we need to fix this app by app? Or is scrolling implemented system-wide?
Chris, Vivien, renominate if needed
blocking-basecamp: ? → -
Flags: needinfo?(jones.chris.g)
Flags: needinfo?(21)
Scrolling is hopefully implemented system wide in
Flags: needinfo?(jones.chris.g)
Flags: needinfo?(21)
Thanks Vivien. So a fix to the issue described here would be inherited system wide. Another reason to address this.
Summary: [Gaia::System] Index Lists Scrolling - Swiping a Small Distance Has No Inertia → List scrolling - swiping a small distance has no inertia
Whiteboard: interaction, UX-P1 → interaction, UX-P1, BerlinWW
Posted patch PatchSplinter Review
I have a small patch I made in the plane. Not perfect but make it much better imo.
Attachment #699659 - Flags: review?(mchen)
(In reply to Vivien Nicolas (:vingtetun) from comment #11)
> Created attachment 699659 [details] [diff] [review]
> Patch
> I have a small patch I made in the plane. Not perfect but make it much
> better imo.

Hi Vivien,

I think you set a wrong reviewer here. I am not a guy for this area.
Comment on attachment 699659 [details] [diff] [review]

Should be r? jlebar
Attachment #699659 - Flags: review?(mchen) → review?(justin.lebar+bug)
Comment on attachment 699659 [details] [diff] [review]

Let's change again my reviewer :)
Attachment #699659 - Flags: review?(justin.lebar+bug) → review?(schien)
Comment on attachment 699659 [details] [diff] [review]

Review of attachment 699659 [details] [diff] [review]:

Great work on fine tuning KineticPanning! :)
Attachment #699659 - Flags: review?(schien) → review+
Component: Gaia::System → General
Comment on attachment 699659 [details] [diff] [review]

This is a simple patch that provide more inertia when the user do little gesture. This is a UX-P1 because doing a small and quick pan gesture in all applications results into an scroll followed by an immediate stops right now.
Attachment #699659 - Flags: approval-mozilla-b2g18?
Does this conflict/relate to bug 827715?
This change is not blocking-basecamp:+ or blocking-b2g:tef+, so we'll default to resolving in v1.0.1 first. You can either land on shira already or wait for mozilla-b2g18 to be opened up to v1.0.1 changes.
Given this is a low risk patch and provides a better user experience, we'll take this on the b2g18 branch now so it gets into v1.0.0 - it's not a blocker so if it doesn't land in time, we will wait for it in 1.0.1
Attachment #699659 - Flags: approval-mozilla-b2g18? → approval-mozilla-b2g18+

Comment 21

7 years ago
Great news, thanks for doing this Vivien!
Does this need to land on inbound/b2g18 still? (I'm assuming b2g18_v1_0_0 isn't going to happen at this point). If you want me to take care of landing it, just set the checkin-needed keyword up top.
Closed: 6 years ago
Resolution: --- → FIXED
Yes, we still want this on b2g18.  Thanks!
Keywords: checkin-needed
Assignee: nobody → 21
Batch edit: bugs fixed on b2g18 since 1/25 branch of v1.0 are fixed on v1.0.1
You need to log in before you can comment on or make changes to this bug.