Closed
Bug 1075248
Opened 10 years ago
Closed 10 years ago
[Lockscreen] Status Bar displays black when locking phone in certain Apps
Categories
(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)
Tracking
(blocking-b2g:2.1+, b2g-v2.2 affected)
RESOLVED
DUPLICATE
of bug 1071706
blocking-b2g | 2.1+ |
Tracking | Status | |
---|---|---|
b2g-v2.2 | --- | affected |
People
(Reporter: onelson, Unassigned)
References
()
Details
(Whiteboard: [2.2-Daily-Testing][systemsfe])
Attachments
(2 files)
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
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Whiteboard: [2.2-Daily-Testing]
Reporter | ||
Comment 1•10 years ago
|
||
Comment 2•10 years ago
|
||
Qawanted for branch checks.
Comment 3•10 years ago
|
||
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.
Comment 4•10 years ago
|
||
I agree this is a duplicate of 1071706, removing qawanted.
Comment 5•10 years ago
|
||
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.
Comment 6•10 years ago
|
||
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.
Status: RESOLVED → REOPENED
blocking-b2g: --- → 2.1+
Resolution: DUPLICATE → ---
Whiteboard: [2.2-Daily-Testing] → [2.2-Daily-Testing][systemsfe]
Comment 7•10 years ago
|
||
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.
Comment 8•10 years ago
|
||
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.
Comment 9•10 years ago
|
||
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!
Comment 10•10 years ago
|
||
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
Comment 11•10 years ago
|
||
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!
Updated•10 years ago
|
Assignee: nobody → mhenretty
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+]
Comment 12•10 years ago
|
||
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.
Assignee: mhenretty → nobody
Comment 13•10 years ago
|
||
Being resolved here => Bug 1071706
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•