[Settings][Color Filter] When changing the contrast, the effect doesn't apply until you tap the screen again.

RESOLVED WONTFIX

Status

defect
RESOLVED WONTFIX
5 years ago
2 years ago

People

(Reporter: rmead, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(b2g-v2.1 affected, b2g-v2.2 affected)

Details

(Whiteboard: [2.1-exploratory-3][b2ga11y backlog], )

Attachments

(1 attachment)

Posted file Flame2.1logcat.txt
Description:
When in the Color Filter screen, if you adjust the contrast via the slider bar, the change in contrast won't take effect until you tap the screen.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141106001204
2) Tap 'Settings'app
3) Scroll down and tap 'Accessibility'
4) Tap 'Color filter'
5) Turn the contrast all the way down or up
  
Actual:
The change won't take effect until you tap the screen
  
Expected: 
The change takes effect as you use the slider bar
  

Flame 2.1(319mb)(KitKat)(Shallow Flash)

Environmental Variables:
Device: Flame 2.1
BuildID: 20141106001204
Gaia: 9658b93b412bdcc0f953d668e8c8e68318c99fb8
Gecko: 76880403db44
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Repro frequency: 100%
See attached: logcat, video - http://youtu.be/D17X5enhmGo
This issue DOES occur on Flame 2.2(319mb)

When in color filter mode, if you change the contrast via the silder bar, the change won't take effect until you tap the screen.

Flame 2.2

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141105160209
Gaia: 7918024c737c4570cacd784f267e28737ae05dea
Gecko: 2114ef80f6ae
Version: 36.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0


This issue does NOT occur on Flame 2.0(319mb) as the 'Color filter' option did not yet exist.

Flame 2.0

Device: Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141105183012
Gaia: 5ee26701a4d8db266bfb203b2179f686ce14d8b6
Gecko: dbf49343e889
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
Not nominating this as a blocker. THe user can easily change the contrast, just a polish bug
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
Depends on: 1055891
(In reply to Derek Harris [:DerekH] from comment #2)
> Not nominating this as a blocker. THe user can easily change the contrast,
> just a polish bug

I believe the root cause is: we change the contrast while updating layer tree (tapping can update the layer tree.). And we change the preference only when we touch up, not when we move the slider bar. Maybe we have to revise the timing of updating this contract preference.
Depends on: 1049824
(In reply to Boris Chiou [:boris] from comment #3)
> (In reply to Derek Harris [:DerekH] from comment #2)
> > Not nominating this as a blocker. THe user can easily change the contrast,
> > just a polish bug
> 
> I believe the root cause is: we change the contrast while updating layer
> tree (tapping can update the layer tree.). And we change the preference only
> when we touch up, not when we move the slider bar. Maybe we have to revise
> the timing of updating this contract preference.

Hi, Eitan, do you have any idea to revise its gaia behavior? Thanks.
Flags: needinfo?(eitan)
(In reply to Boris Chiou [:boris] from comment #4)
> (In reply to Boris Chiou [:boris] from comment #3)
> > (In reply to Derek Harris [:DerekH] from comment #2)
> > > Not nominating this as a blocker. THe user can easily change the contrast,
> > > just a polish bug
> > 
> > I believe the root cause is: we change the contrast while updating layer
> > tree (tapping can update the layer tree.). And we change the preference only
> > when we touch up, not when we move the slider bar. Maybe we have to revise
> > the timing of updating this contract preference.
> 
> Hi, Eitan, do you have any idea to revise its gaia behavior? Thanks.

Yeah. You need a repaint to trigger this effect, and I guess that doesn't happen after a touchup, like you said. I originally suggested we do that through some nsIDOMWindowUtils method I can't remember now. Ultimately it kind of resolved itself because when a user pressed the switches there are a few animation frames that happen that refresh the painting. But the slider seems to be another case, so we may need to force a refresh.
Flags: needinfo?(eitan)
Whiteboard: [2.1-exploratory-3] → [2.1-exploratory-3][b2ga11y stabilitiy]
Whiteboard: [2.1-exploratory-3][b2ga11y stabilitiy] → [2.1-exploratory-3][b2ga11y backlog]
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.