Closed Bug 995532 Opened 6 years ago Closed 2 years ago

[camera] buttons don't consistently highlight when tapped

Categories

(Core :: DOM: Core & HTML, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED WONTFIX
tracking-b2g backlog

People

(Reporter: tif, Unassigned)

References

Details

(Keywords: qawanted, Whiteboard: ux-tracking [fxos:media])

STR

Open camera and take a few photos
Go into preview and select delete
Tap either cancel or delete

Expected
Blue highlight state

Actual
The highlight only works some of the time
These buttons are simply relying on the CSS :active state to change their highlight color. A patch for Bug 986752 was landed last week to resolve issues with :active states getting stuck, but I think there are remaining issues in Gecko with CSS :active states.
(In reply to Justin D'Arcangelo [:justindarc] from comment #1)
> These buttons are simply relying on the CSS :active state to change their
> highlight color. A patch for Bug 986752 was landed last week to resolve
> issues with :active states getting stuck, but I think there are remaining
> issues in Gecko with CSS :active states.

justin: Do you know which component we should move this to? Did you make any graphics friends in your :active travels?
Flags: needinfo?(jdarcangelo)
Wilson: The issues I was working on with :active were dealing with multiple touches causing it to remain 'stuck' (see Bug 997235). Vivien was the one who patched it, but I'm almost certain it wasn't a graphics issue as much as it was an events issue.
Flags: needinfo?(jdarcangelo)
Whiteboard: interaction-design
It seems like this applies to more than just the delete confirmation dialogue. We are seeing it in many places.
Summary: [camera] delete dialogue - buttons don't consistently highlight when tapped → [camera] buttons don't consistently highlight when tapped
Several other CSS :active bugs that may be related and/or require discussion:

Bug 997235 - Followup to bug 986752 - CSS :active states get stuck with multiple on-screen touches
Bug 1009684 - Define a UX specification for handling CSS :active states on touch devices
Blocks: 994991
Whiteboard: interaction-design → interaction-design, ux-most-wanted
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → Other
Chatted with Rob and we think this needs a look from Casey.
Flags: needinfo?(kyee)
This is a platform bug relating to CSS :active state. This should *not* be worked around at the Camera/Gaia layer. See justindarc's comment 5.
How do we push this issue to the right people?
Flags: needinfo?(hkoka)
Removing the flag for Casey based on comment #7 and Hema is already flagged to reassign to a Platform dev.
Flags: needinfo?(kyee)
Andrew,

Based on the comments and related bugs on css :active state, moving this to Core->DOM. Please help triage this into the right component and find an owner for this issue.

Thanks
Hema
Component: Gaia::Camera → DOM
Flags: needinfo?(hkoka) → needinfo?(overholt)
Product: Firefox OS → Core
Whiteboard: interaction-design, ux-most-wanted → interaction-design, ux-most-wanted [fxos:media]
CSS :active states seem to be *completely* broken using latest nightly. Simple test case with a couple buttons with :active styles here: http://jsbin.com/vorib
> CSS :active states seem to be *completely* broken using latest nightly. 

On which OS? Your testcase works fine for me in todays nightly on OSX....
Flags: needinfo?(jdarcangelo)
Firefox OS
Flags: needinfo?(jdarcangelo)
Hardware: Other → ARM
CSS :active states seem to be way more broken than usual today:

https://www.youtube.com/watch?v=t9PqdLsNdMo

Using latest build on Nexus4:

Gaia      101c500903a2477f9de1ea5ce523b9e0be4d45d0
Gecko     https://hg.mozilla.org/mozilla-central/rev/41a54c8add09
BuildID   20140519040204
Version   32.0a1
kats says bug 1013378 should fix most of the recent :active bustage (likely regressed by bug 964750).
Flags: needinfo?(overholt)
(In reply to Andrew Overholt [:overholt] from comment #15)
> kats says bug 1013378 should fix most of the recent :active bustage (likely
> regressed by bug 964750).

qawanted to test it out with above fixes in.
Whiteboard: interaction-design, ux-most-wanted [fxos:media] → interaction-design, ux-most-wanted [fxos:media] qawanted
blocking-b2g: --- → backlog
Keywords: qawanted
Whiteboard: interaction-design, ux-most-wanted [fxos:media] qawanted → interaction-design, ux-most-wanted [fxos:media]
This issue DOES reproduce on the latest v2.0 Flame build:

Environmental Variables:
Device: Flame 2.0
BuildID: 20140609040203
Gaia: 12af93123c5db55212d51fe235d39f21209a1eaa
Gecko: 9305a8ec77fe
Version: 32.0a1
Firmware Version: V10G-2

-

Cancel and Delete do not always turn blue when the user 'taps' them. While testing, these buttons only appeared blue when I held the buttons before selecting them.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage?][lead-review+]
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(jmitchell)
blocking-b2g: backlog → ---
Is this still valid or should we close? Thanks!
Keywords: qawanted
Whiteboard: interaction-design, ux-most-wanted [fxos:media] → ux-tracking [fxos:media]
I don't think we are going to work on this anymore. Closing.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.