Closed Bug 1035084 Opened 10 years ago Closed 10 years ago

The statusbar disappears from lockscreen

Categories

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v1.4 unaffected, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.0 S6 (18july)
blocking-b2g 2.0+
Tracking Status
b2g-v1.4 --- unaffected
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: lchang, Assigned: crdlc)

References

Details

(Keywords: regression, Whiteboard: [systemsfe])

Attachments

(3 files)

STR: 1. enable lockscreen from settings app. 2. launch a "fullscreen" app which doesn't contain statusbar. (e.g. camera, gallery, etc) 3. press power button to turn off the screen. 4. turn on the screen by pressing power button again. 5. the statusbar disappears!
It's actually caused by Bug 1016822, at least this is what I can bisected out. Since it's an old bug and revert would be failed, I need to check it manually.
Mark keywords to make sure I didn't bisect out the wrong bug.
QA Wanted first to get a screenshot, then complete what comment 2 is asking.
Blocks: 1016822
No longer depends on: 1016822
blocking-b2g: --- → 2.0?
blocking-b2g: 2.0? → ---
QA Contact: ckreinbring
The bug repros on Flame 2.1, Flame 2.0 and Buri 2.0 Flame 2.1 Build ID: 20140710040201 Gaia: 4e4e579b4b1e35f863ed43ef6ba840f49bfd761c Gecko: cb75d6cfb004 Platform Version: 33.0a1 Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 Flame 2.0 Build ID: 20140710000201 Gaia: 35a9b715e7348ec738ff6c8a59f50190390a06f2 Gecko: 94714370dfc3 Platform Version: 32.0a2 Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Buri 2.0 Build ID: 20140710094050 Gaia: 1bd6e8957ccf310b2f75ba5695b058a2e284df3a Gecko: f0e91a6bfd1b Platform Version: 32.0a2 Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Actual result: After launching the Video or Gallery app then pressing the power button, pressing the power button again to show the lockscreen will show a blank area at the top where the status bar is supposed to be. -------------------------------------------------------------------------------------------------------- The bug does not repro on Flame 1.4 Build ID: 20140710000202 Gaia: b0e9b4bdb39c5eb93a6783a34624ffc84f62b126 Gecko: ccabaf8826a4 Platform Version: 30.0 Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0 Actual result: After launching the Video or Gallary app then pressing the power button, pressing the power button again to show the lockscreen will show the status bar at the top of the screen.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
returning to comment 2 request for regression-window.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
We should really also get a blocking triage analysis on this bug as well. If it's non-blocking, then it's not worth getting a window on.
Flags: needinfo?(jmitchell)
Nomming as a blocker - Users will often just check the lockscreen for the purpose of looking at the status bar. Scenarios are to ensure that their alarm is set (as indicated by the alarm icon), to check their battery status, to ensure they have power-draining features turned off (blue-tooth, wi-fi), etc.
blocking-b2g: --- → 2.0?
Flags: needinfo?(jmitchell)
Regression window: Last working Build ID: 20140527013003 Gaia: 6a391274cd436f8f0d1fad2db8c6b4805703259c Gecko: cbe4f69c2e9c Platform Version: 32.0a1 Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 First broken Build ID: 20140527133002 Gaia: bc6f07c149770c6e6dfbea941ac65138dc364a15 Gecko: 448f2153d6d3 Platform Version: 32.0a1 Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Working Gaia / Broken Gecko = OK Broken Gaia / Working Gecko = Fail Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/6a391274cd436f8f0d1fad2db8c6b4805703259c...bc6f07c149770c6e6dfbea941ac65138dc364a15 B2G-Inbound window: Last working Build ID: 20140527023021 Gaia: e6dd9744778e26241bd65dda51f3db43ec9e40c4 Gecko: 5b2a6a5af87a Platform Version: 32.0a1 Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 First broken Build ID: 20140527053007 Gaia: 9c7e0ace045074c08b96b198aaf6c5d39ce302dd Gecko: 3ebd3510cb7c Platform Version: 32.0a1 Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Working Gaia / Broken Gecko = OK Broken Gaia / Working Gecko = Fail Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/e6dd9744778e26241bd65dda51f3db43ec9e40c4...9c7e0ace045074c08b96b198aaf6c5d39ce302dd
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #1) > It's actually caused by Bug 1016822, at least this is what I can bisected > out. > > Since it's an old bug and revert would be failed, I need to check it > manually. This bug did not appear in the push-log, so it might not be the cause
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(gweng)
Kevin - out of that pushlog, your bug 971552 is the only one that looks like it might affect the lockscreen? Can you take a look?
Flags: needinfo?(kgrandon)
(In reply to Joshua Mitchell [:Joshua_M] from comment #11) > Kevin - out of that pushlog, your bug 971552 is the only one that looks like > it might affect the lockscreen? Can you take a look? I find it highly doubtful that bug 971552 regressed this. Greg's original bisection of bug 1016822, or potentially bug 1010651 is much more likely as it touches on some statusbar/transforms diffs.
Flags: needinfo?(kgrandon)
ok. there were a few issues with other visual lock-screen bugs 'interfering' with getting a solid regression window so we'll look at bug 1010651 (which is in this pushlog) and if that is a dead end we'll go back and try the regression-window process again. (possibly in Buri instead) Thanks for your help / time. Christian - can you take a look in regards to bug 1010651
Flags: needinfo?(crdlc)
blocking-b2g: 2.0? → 2.0+
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Sorry, but I'm a little confused about the regression window and the dependency. If this is really caused by Bug 1010651, it has been marked as duplicated. And the duplicated Bug 1016822 has been marked as RESOLVED FIXED, therefore there is no bug need to be fixed or has been reopened.
Flags: needinfo?(gweng)
taking a look here
Flags: needinfo?(crdlc)
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
Blocks: 1014824
No longer blocks: 1016822
Attached file Github pull request
Attachment #8455161 - Flags: review?(alive)
Whiteboard: [systemsfe]
Attachment #8455161 - Flags: review?(alive) → review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Attached video video
This issue has been verified successfully on Flame 2.0 and 2.1 See attachment: Verify_1035084.MP4 Reproducing rate: 0/5 Flame2.0 build: Gaia-Rev 856863962362030174bae4e03d59c3ebbc182473 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/e40fe21e37f1 Build-ID 20141207000206 Version 32.0 Flame2.1 build: Gaia-Rev 38e17b0219cbc50a4ad6f51101898f89e513a552 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a Build-ID 20141205001201 Version 34.0
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: