Description: When locking their phone in certain locations, the user is able to carry on a black tinted status bar through to the lock screen, signifying where the user had locked their screen previously. This appears to occur whenever the user transitions from an app with a white background UI: - Settings - Usage - Browser Repro Steps: 1) Update a Flame device to BuildID: 20140930040206 2) Open 'Settings' app. 3) Lock screen. 4) Wake phone and observe status bar at top right. Actual: Status bar elements display in black. Expected: Status bar elements display in white. ------------------------------------------------ Environmental Variables: Device: Flame 2.2 Master BuildID: 20140930040206 Gaia: 77ef35f5429bc3dfe9ca192b9aacc3c0bf8857de Gecko: 7c24470b6b3a Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf Version: 35.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Repro frequency: 5/5 See attached: logcat comparison screenshot video- http://youtu.be/DyDgjfDKS8c

Qawanted for branch checks.

This appears to be a dupe of 1071706 but the fix was uplifted to master for that bug on 9/26 so this should be fixed by now.

I agree this is a duplicate of 1071706, removing qawanted.

I think is more a dupe of 1074991 (which is still active). The repro steps for 1071706 required specifically leaving the task switcher open when going to the lock screen.

This still happens with a 2.1 build from today. My STR: Open settings app Open Task manager and wait 2 min until phone goes to sleep Press power button to wake up and you see the dark icons.

Just a note for easier reproducing, you don't have to wait the 2 minutes for the phone to sleep in the STR in comment 6. Pressing the power button also works.

Sorry I'm confused with the duplicating status. While I'm working on Bug 1074991 for master, this looks like chiefly for v2.1? Or, if this bug is for master and v2.1, Bug 1074991 looks duplicated? Moreover, the similar issue looks has been resolve via Bug 1071706, although I now found the patch may be not so correct. This is what I now have: 1. Bug 1074991: for master (2.2); now it's 2.2? 2. Bug 1075248: for 2.1, now is 2.1+, but *not* for master, since we have Bug 1074991 3. Bug 1071706: for *master and v2.1*, which had solved the issue (or a similar issue), but it may be broken What I concerns is if 2., the Bug 1075248, is a v2.1 blocker and just like what we do usually, would fix both master and v2.1, the Bug 1074991 would be a duplicated.

Clarification (at least an attempt): We have 2 main 'different' problems: 1.- When going to the lockscreen after the *task switcher* (important), the icons remain dark. That was fixed in master with Bug 1071706. I just checked it, and the uplift never fixed 2.1 (although it did fix master), probably because we have 2 different task switchers in 2.1 and 2.2. *So, 2.1 is affected* 2.- When going to the lockscreen after a 'dark-icons' app (no task switcher), the icons remain dark. That started happening as a regression of Bug 1057198. *2.1 is not affected*, you need to go to the task switcher for making it happen. I'm going to work on both and add UI tests for both cases in order to make them not happening again. Thanks!

Would it makes sense to change the line here [1] from ` if (this.isLocked()) {` to ` if (this.isLocked() && app.CLASS_NAME !== 'LockScreenWindow') {`? It is pretty much what we want to do (ignoring app setAppearance calls when the phone is locked, but letting the lockscreen setAppearance go through) and it's a small change easily upliftable where it's needed (and easily testable ;). [1] https://github.com/mozilla-b2g/gaia/blob/d66bf704c0c0014ab518f041cd89a2b7e841be31/apps/system/js/statusbar.js#L532

I was working on setting app = lockscreenWindowManager.getInstance() instead of returning when the phone is locked, but I think both approaches are valid. Let me check which one makes more sense. Thanks!

I didn't have a chance to get to this today, so un-assigning myself for the moment. Alberto, feel free to steal this if you have the time. Otherwise I will try again after I finish bug 1074123.

Being resolved here => Bug 1071706