Settings list item is not highlighted when the touch is fast

RESOLVED INVALID

Status

Firefox OS
Gaia::Settings
P1
critical
RESOLVED INVALID
5 years ago
5 years ago

People

(Reporter: leo.bugzilla.gecko, Assigned: gerard)

Tracking

unspecified
1.1 QE5
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:leo+)

Details

(Reporter)

Description

5 years ago
In settings menu, when the user selects an item with a simple touch (not too long), the item is not highlighted.

1. Title : Settings list item is not highlighted when the touch is fast
2. Precondition : none.
3. Tester's Action : Enter Settings menu and select an item (ex. Language) with a simple touch (not too long).
4. Detailed Symptom (ENG.) : The item is not highlighted.
5. Expected : The selected item should be highlighted.
6.Reproducibility: Y
1)Frequency Rate : 100%

If the touch event is a little long, the item is highlighted normally.
The same can be verified when the back button ("<") is pressed to return from the Language settings to the main settings screen.

Applications like Homescreen, FMRadio and Dial, the highlight of icons and buttons have a normal behavior.

Comment 1

5 years ago
About this issue, Mozilla fixed in Bug 857105 - Keep the tapped item highlighted while the panel loads
But this patch has the side-effect like this, Bug 889717 - [Settings] Do not work when you are scrolling and select a menu 

We need to check again. Please check about this.
blocking-b2g: --- → leo+
(Assignee)

Comment 2

5 years ago
v1-train or master ?
Flags: needinfo?(leo.bugzilla.gecko)

Comment 3

5 years ago
The patch of Bug 889717 has uplifted in only v1-train.
Flags: needinfo?(leo.bugzilla.gecko)
(Assignee)

Comment 4

5 years ago
(In reply to Leo from comment #1)
> About this issue, Mozilla fixed in Bug 857105 - Keep the tapped item
> highlighted while the panel loads
> But this patch has the side-effect like this, Bug 889717 - [Settings] Do not
> work when you are scrolling and select a menu 
> 
> We need to check again. Please check about this.

After discussing with :rik, he's not very happy with the solution of bug 889717, so I'm going to look into reverting that one and provide a fix that would fix the preesnt bug at the same time.
(Assignee)

Comment 5

5 years ago
After reverting bug 889717 I still see the issue, especially the back button case described.
(Assignee)

Comment 6

5 years ago
(In reply to Alexandre LISSY :gerard-majax from comment #5)
> After reverting bug 889717 I still see the issue, especially the back button
> case described.

Nevermind. With patch from bug 889717, I have the issue on any item, without this patch, I don't have the issue. In both cases, the back button exposes the issue, so I'm unsure whether it's part of the same bug.
Yeah, we should open a bug about highlighting the back button. I haven't worked on that in bug 857105.

I think the best way to solve bug 889717 would have been to prevent elements to get the focus state while scrolling, instead of removing the focus styles.

hyuna.cho: In general, if you think a patch created a regression, mark it as a blocker of the original bug. That helps keep track of the problems a patch introduced and also let anyone who was cc-ed on the original bug to know that there is an issue with it.
Blocks: 889717, 857105
(Assignee)

Updated

5 years ago
Assignee: nobody → lissyx+mozillians
(Assignee)

Comment 8

5 years ago
(In reply to Anthony Ricaud (:rik) from comment #7)
> Yeah, we should open a bug about highlighting the back button. I haven't
> worked on that in bug 857105.
> 
> I think the best way to solve bug 889717 would have been to prevent elements
> to get the focus state while scrolling, instead of removing the focus styles.
> 
> hyuna.cho: In general, if you think a patch created a regression, mark it as
> a blocker of the original bug. That helps keep track of the problems a patch
> introduced and also let anyone who was cc-ed on the original bug to know
> that there is an issue with it.

As discussed on IRC I'm working on the solution you suggested.
(Assignee)

Comment 9

5 years ago
After working on this and testing something, with bug 889717 reverted, I'm reproducing the issue :(
(Assignee)

Comment 10

5 years ago
After careful observation, if you tap and stay pressed on the screen, you can notice a delay before the item is being highlighted.
(Assignee)

Comment 11

5 years ago
I'm going to check whether sending focus state is okay when the user taps to stop scrolling, which is the root of bug 889717.
(Assignee)

Comment 12

5 years ago
FYI from my testing, we are getting both ':focus' css pseudo class and the 'focus' event, on the <a> items that are parts of the settings list.

Updated

5 years ago
Severity: normal → critical
Priority: -- → P1
Target Milestone: --- → 1.1 QE5
I've reverted the patch in bug 889717 so this is no longer an issue. We'll discuss how to fix bug 889717 in bug 889717.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.