804315 - Scrolling through a list triggers button highlights

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Peter La]

When scrolling up and down through lists using a swipe motion, the blue highlight for a row will appear momentarily and disappear.  This behaviour is distracting and creates a lowered sense of quality.  The blue highlight should not appear on a rapid swipe, but only if the user's finger rests on the screen without moving for a specified amount of time (usually quite short, like < .5 sec as a ballpark).  The exact time will need to be found through trial and error.

This is not 'technically' a performance issue, but it affects the feeling of fluidity.

Tested on: otoro_2012-10-22_ics_us

Comment 1

[Peter La]

Ps. See settings screen for an example of this behaviour.

Comment 2

[Gordon Brander :gordonb]

In "apps/settings/style/lists.css":

    ul li.active,
    ul li:active {
      background-color: #ddf;
      color: #222;
    }

...handles highlighting items in settings. "ul li:active" is causing the highlight. "ul li.active" seems to be unused.

It seems the intent is to map the :active pseudo-selector to tap gestures. I believe the right way to fix this would be to distinguish swipes as distinct from taps at a platform level. Thoughts?

Comment 3

[Peter La]

Rewriting with perf/ux-trust bug template.

--

What makes it feel slow/broken?

The blue highlight bar renders when I'm swiping through a list.  It should only render if I have my finger held stationary on a list item for a certain amount of time.

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

No, but it makes list scrolling look broken.

How does this make you feel?

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

Device: Unagi, Nov. 22 Nightly.

Details:

There should be a built in delay of approx. 250-400ms where a highlight state will not be rendered if the user scrolls after touching the screen (ie. a swipe).

Bonus: can you attach a video of the problem?
Yes

Comment 4

[Josh Carpenter [:jcarpenter]]

(In reply to Peter La from comment #3)
> There should be a built in delay of approx. 250-400ms where a highlight
> state will not be rendered if the user scrolls after touching the screen
> (ie. a swipe).

Agreed. Gordon and I chatted about this in Paris and arrived at a similar initial conclusion. 

cc'ing Vivien and Chris Jones. 

Every time I scroll it gives me the impression I'm about to trigger a button press. It pops up even more annoyingly in form-heavy pages, wherein the keyboard opens/closes when I'm trying to scroll a page full of fields (eg: Contacts > New). That is maddening.

Comment 5

[Josh Carpenter [:jcarpenter]]

Vivien and Chris, please see above.

Comment 6

[Peter La]

Nominating for bb+, as this is a quality issue on a fundamental, pervasive interaction.

Comment 7

[Josh Carpenter [:jcarpenter]]

Strongly agree with Peter. This is extremely janky and appears to be causing serious usability problems with keyboard, as explained in commen#4.

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This was fixed for content in bug 823619.

It's not fixed for system UI like popups generated by <select> boxes.

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #9)
> This was fixed for content in bug 823619.
> 
> It's not fixed for system UI like popups generated by <select> boxes.

I told you 50ms is too short ;)

Comment 11

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

No attempt was made to fix this bug for system UI.  It's still receiving non-spec mouse events.

Comment 12

[Josh Carpenter [:jcarpenter]]

I spoke w/ CJones here in Berlin WW and it sounds like all we need to do here is extend the time out for the touch events so that we're not quite so aggressive about triggering touch events. This is the approach taken by competitor OS' as well.

Comment 13

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch

Hey Chris I told you 50ms was too small ;)

I take this value with Josh sitting next to me so it seems like a good compromise.

Comment 14

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Comment on attachment 700098 [details] [diff] [review]
Patch

This will regress activating tap targets in pannable frames, but josh and discussed having the important ones manually activate themselves (like settings list items).  So ok by me.

Comment 15

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to Josh Carpenter [:jcarpenter] from comment #12)
> I spoke w/ CJones here in Berlin WW and it sounds like all we need to do
> here is extend the time out for the touch events so that we're not quite so
> aggressive about triggering touch events. This is the approach taken by
> competitor OS' as well.

And just to add, they get away with that by activating the tap target for a "logical" period after it's tapped.

Comment 16

[:Margaret Leibovic]

Does this patch need to land?

Comment 17

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Comment on attachment 700098 [details] [diff] [review]
Patch

Trivial safe patch for UX-P1 issue encountered when scrolling tappable buttons inside a pannable frame (e.g., in main settings screen).

Comment 18

[Doug Turner (:dougt)]

why not just make the change in b2g.js pref file so that it doesn't change the behavior of any other application?

Comment 19

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to :Margaret Leibovic from comment #16)
> Does this patch need to land?

Yep, oops.

(In reply to Doug Turner (:dougt) from comment #18)
> why not just make the change in b2g.js pref file so that it doesn't change
> the behavior of any other application?

The code that looks at this pref is only used by b2g atm.

Comment 20

[Alex Keybl [:akeybl]]

This isn't blocking-basecamp:+ or blocking-b2g:tef+, so we'll get this into v1.0.1. Feel free to land to the shira Gecko branch, and mark the status-b2g18:fixed (given the fact that shira will merge to mozilla-b2g18).

Comment 21

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 700098 [details] [diff] [review]
Patch

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

Comment 22

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ff6901f603ec
https://hg.mozilla.org/releases/mozilla-b2g18/rev/d04a8081ae0d

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/ff6901f603ec