1223216 - Device screen brightness does not change/dim to proper setting until after reaching the lockscreen on start-up.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

[Martin Shuman [:Marty]]

Attachment: logcat_brightness-dim-startup.txt

Description:
When the device is booted up, the screen will display at full brightness for the opening FxOS splash pages. The device will not change to the actual brightness configured in Settings > Display until after the device reaches the lock screen.

This issue appears to be performance related, as it takes longer for the Flame device to switch to the proper brightness than the Aries device. This issue also seems to have become more pronounced from previous builds, as the RC4 build is not as severe as the most recent master build, and does not occur on the 2.2 flame branch at all.

Repro Steps:
1) Update a Aries to 20151109152230
2) Open Settings > Display and change the brightness down to 1/3
3) Restart the device.
4) Watch the screen brightness, and note the time when the brightness changes to the proper level.

Actual:
The screen brightness does not dim to the proper level until after reaching the lockscreen on start-up.

Expected:
The screen brightness dims to the proper level before reaching the lockscreen on start-up.

Environmental Variables:
Device: Aries 2.6
Build ID: 20151109152230
Gaia: 23cab7ea0fcecab7689d340baf604e024e88f9a3
Gecko: e1ef2be156de1dad31bb4189a51b178b12b23340
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 45.0a1 (2.6)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Repro frequency: 5/5
See attached: Logcat, Video (URL)

**************************************

This issue DOES occur on the latest Aries 2.5, Flame 2.6 and 2.5 builds as well as the Aries RC4 build.
The screen brightness does not dim to the proper level until after reaching the lockscreen on start-up.  This issue is more pronounced on Flame than on Aries.

Environmental Variables:
Device: Aries 2.5
BuildID: 20151109214310
Gaia: 9f823b3b2902558bad224384e1abddd1bb35d93a
Gecko: 5d8c923e44f54f1da2b1b87bf1400a4a43d1ef1a
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 44.0a2 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Environmental Variables:
Device: Aries 2.5 (RC4)
BuildID: 20150619225606
Gaia: 4c06ed88ddccaba8dc941e5006bd2a9e57306f07
Gecko: 7c1a6b1151a1539186b950a144387e2d7f378d1b
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 41.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Environmental Variables:
Device: Flame 2.6
BuildID: 20151109030231
Gaia: c3436122d678911d04b8f491724596116890ff9b
Gecko: e2a910c048dc82fc3be53475f18e7f81f03e377b
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 45.0a1 (2.6) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Environmental Variables:
Device: Flame 2.5
BuildID: 20151109004552
Gaia: cf646c52bb947af28329b0a100df91d1b1f2a907
Gecko: 4eafef5b80f8985c94c4a067f130d37513e1a581
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a2 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

**************************************

This issue does NOT occur on the latest Flame 2.2 build.
The screen brightness dims to the proper level at the blue FxOS splash page, before reaching the lockscreen on start-up.

Environmental Variables:
Device: Flame 2.2
BuildID: 20151109032503
Gaia: 885647d92208fb67574ced44004ab2f29d23cb45
Gecko: e6ea91190b53
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 1

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Not nominating to block, but let's get a window here.

Comment 2

[Pi Wei Cheng [:piwei] (inactive)]

According to bug 1186568 comment 3, this could be by design.

Comment 3

[Max Murrell [MMurrell]]

This issue appears to be caused by changes from Bug 1094759 

b2g Regression Window
Last Working
Environmental Variables:
Device: Flame 2.5
BuildID: 20150604012244
Gaia: e0fbadeb78a96137f071d9be7a47ef9fe882d17f
Gecko: 64ce149fabf1
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 41.0a1 (2.5) 
Firmware Version: v18D

First Broken
Environmental Variables:
Device: Flame 2.5
BuildID: 20150604020845
Gaia: c1ef854924f18357832ddcf98dc6c42391d5599e
Gecko: 4f7e7631e277
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 41.0a1 (2.5) 
Firmware Version: v18D

Last Working gaia / First Broken gecko - Issue does not occur
Gaia: e0fbadeb78a96137f071d9be7a47ef9fe882d17f
Gecko: 4f7e7631e277

First Broken gaia / Last Working gecko - Issue does occur
Gaia: c1ef854924f18357832ddcf98dc6c42391d5599e
Gecko: 64ce149fabf1

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/e0fbadeb78a96137f071d9be7a47ef9fe882d17f...c1ef854924f18357832ddcf98dc6c42391d5599e

Comment 4

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Gregor you did some reviews of bug 1094759.  Can you please take a look at this or pass it on to someone more suited?

Comment 5

[Gregor Wagner [:gwagner]]

(In reply to Jayme Mercado [:JMercado] from comment #4)
> Gregor you did some reviews of bug 1094759.  Can you please take a look at
> this or pass it on to someone more suited?

Etienne, can you help out here?

Comment 6

[Etienne Segonzac (:etienne)]

(In reply to Gregor Wagner [:gwagner] from comment #5)
> (In reply to Jayme Mercado [:JMercado] from comment #4)
> > Gregor you did some reviews of bug 1094759.  Can you please take a look at
> > this or pass it on to someone more suited?
> 
> Etienne, can you help out here?

The |ScreenManager| is already loaded as part of the core, so nothing obvious to be done with regard to the boot sequence.

That said glancing at the ScreenManager code I don't see anything enforcing the "expected behavior" here. It just happened to work before (if it was) but it was probably racy.

Comment 7

[Tim Guan-tin Chien [:timdream] (please needinfo)]

It might worthy to check the time mozSetting observer calls the ScreenManager with the user-set value. bug 1094759 changed the timing of initial mozSetting a lot and I would not be surprised if the initial get() is deferred because of it.

Comment 8

[BMO Automation]

Firefox OS is not being worked on