Closed
Bug 1083231
Opened 10 years ago
Closed 10 years ago
[Lockscreen] Unable to wake up phone with a short press of power button
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
VERIFIED
FIXED
mozilla36
Tracking | Status | |
---|---|---|
b2g-v2.1 | --- | unaffected |
b2g-v2.2 | --- | verified |
People
(Reporter: smiko, Assigned: gyeh)
References
()
Details
(Keywords: regression)
Description: The lockscreen is briefly shown and then the phone falls back asleep when the user presses the power button while the phone is asleep. Repro Steps: 1: Update a Flame to 20141015040201 2: Short press the power button. Actual: The lockscreen is briefly shown and then the phone falls back asleep. Expected: The device remains awake Device: Flame 2.2 (319mb/full flash) BuildID: 20141015040201 Gaia: 5f1f0960ae9d22acf2a324ad37a48174d6df87f6 Gecko: 62f0b771583c Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 36.0a1 (2.2) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Notes: 1: This issue occurs more frequently when pressing the power button from the homescreen. 2: Unable to grab a logcat for this issue as the phone disconnects when asleep Repro frequency: 8/10 Video clip: http://youtu.be/yMTWbNKIsv4
Reporter | ||
Comment 1•10 years ago
|
||
This issue does NOT occur on Flame 2.1 (319mb/full flash) Actual result: The device remains awake Environmental Variables: Device: Flame 2.1 BuildID: 20141015001201 Gaia: 379ea4c9dd6d3f8ca2f79ce59c15f6afe6e557c3 Gecko: 4853208cb48a Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 34.0 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.1:
--- → unaffected
status-b2g-v2.2:
--- → affected
Flags: needinfo?(pbylenga)
Keywords: smoketest
Comment 2•10 years ago
|
||
[Blocking Requested - why for this release]: Functional regression of a core feature that fails smoke tests. Requesting a window.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Reporter | ||
Comment 3•10 years ago
|
||
Workaround: The user can wake up the phone with a long press of the power button.
Reporter | ||
Comment 4•10 years ago
|
||
Workaround: The user can wake up the phone with a long press of the power button.
Reporter | ||
Comment 5•10 years ago
|
||
Workaround: The phone can be woken up with a long press of the power button.
Updated•10 years ago
|
QA Contact: jmercado
Reporter | ||
Comment 6•10 years ago
|
||
After further investigation we found that this issue ONLY repros prior to performing actions after unlocking the phone. STR: 1: Unlock the phone 2: From the homescreen, immediately lock and unlock the phone. Notes: 1: If the user opens an app or does any type of action between steps 1 and 2, the lockscreen will flicker but will then be displayed.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Comment 7•10 years ago
|
||
With this new pre-requisites this isn't a smoke test blocker although still a critical regression.
Comment 8•10 years ago
|
||
This issue seems to have been caused by bug 989198. Mozilla-inbound Regression Window Last Working Environmental Variables: Device: Flame 2.2 BuildID: 20141013192558 Gaia: 4f86c631e0465c0e56ccebeb1324fd28be9ea32f Gecko: e0c4c804b279 Version: 36.0a1 (2.2) Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 First Broken Environmental Variables: Device: Flame 2.2 BuildID: 20141014001056 Gaia: 4f86c631e0465c0e56ccebeb1324fd28be9ea32f Gecko: 94d1b30bde00 Version: 36.0a1 (2.2) Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Last Working gaia / First Broken gecko - Issue DOES occur Gaia: 4f86c631e0465c0e56ccebeb1324fd28be9ea32f Gecko: 94d1b30bde00 First Broken gaia / Last Working gekko - Issue does NOT occur Gaia: 4f86c631e0465c0e56ccebeb1324fd28be9ea32f Gecko: e0c4c804b279 Gaia Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e0c4c804b279&tochange=94d1b30bde00
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qaurgent,
regressionwindow-wanted
Comment 9•10 years ago
|
||
Possibly broken by bug 989198 ? NI to Patch Author to investigate
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(gyeh)
QA Contact: jmercado
Comment 11•10 years ago
|
||
I reproduced this and printed |evt.detail.type| received at https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/hardware_buttons.js#L193 1. short press 'Power' to turn screen off, hardware_buttons received event like this I/GeckoConsole(18436): Content JS LOG: [HB] type = sleep-button-press I/GeckoConsole(18436): Content JS LOG: [HB] type = sleep-button-release 2. long press 'Power' to turn screen on, hardware_buttons received event like this I/GeckoConsole(18436): Content JS LOG: [HB] type = sleep-button-press I/GeckoConsole(18436): Content JS LOG: [HB] type = sleep-button-release 3. short press 'Power' to turn screen on, hardware_buttons received event like this I/GeckoConsole(18436): Content JS LOG: [HB] type = sleep-button-press I/GeckoConsole(18436): Content JS LOG: [HB] type = sleep-button-release I/GeckoConsole(18436): Content JS LOG: [HB] type = sleep-button-press I/GeckoConsole(18436): Content JS LOG: [HB] type = sleep-button-release I/GeckoConsole(18436): Content JS LOG: [HB] type = sleep-button-press I/GeckoConsole(18436): Content JS LOG: [HB] type = sleep-button-release I/GeckoConsole(18436): Content JS LOG: [HB] type = sleep-button-press I/GeckoConsole(18436): Content JS LOG: [HB] type = sleep-button-release I got four pair of sleep-button-press/sleep-button-release, thus Gaia thought it was meant to turn screen off.
Assignee | ||
Comment 12•10 years ago
|
||
Tzu-Lin, thanks for your detailed information. I'll take a look at it and update my observations here soon!
Flags: needinfo?(gyeh)
Assignee | ||
Comment 14•10 years ago
|
||
Two parts should be fixed for this bug. 1. No need to forward keyboard event from BrowserElementChild to BrowserElementParent since we've already dispatched the keyboard event to both child and parent. 2. No need to send chrome event in shell.js for before/after keybaord events. And, we should not send chrome events for keyboard events generated by chrome window.
Assignee | ||
Updated•10 years ago
|
Component: Gaia::System::Lockscreen → DOM
Product: Firefox OS → Core
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → gyeh
Comment 15•10 years ago
|
||
Please backout bug 989198 then, and fix the issues in that bug (unless you can _quickly_ fix the issues in this bug).
Comment 16•10 years ago
|
||
Bug 989198 was backed out. Please remember to include this fix when it re-lands.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Assignee | ||
Comment 17•10 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #15) > Please backout bug 989198 then, and fix the issues in that bug (unless you > can _quickly_ fix the issues in this bug). I've already discussed with Kanru regarding to the first part I mentioned in comment 14 yesterday, and I think it should be a quick fix. For the second issue, I also have a solution but I'm not sure if it's a good one. Will ask Fabrice for suggestions. I don't know why we directly backout bug 989198 without asking any information like ETA.
(In reply to Gina Yeh [:gyeh] [:ginayeh] from comment #17) > I don't know why we directly backout bug 989198 without asking any > information like ETA. Backing out isn't a punishment; it's giving you a chance to fix the problem while not inconveniencing everyone else. Relanding once you've fixed the problem is easy. Having bugs like this in the tree for days (especially more than one a week) makes it hard for people to use nightly builds of the phone as their main phone. Yet having the people who are building the phone using it as their phone is one of the best ways we have to improve the quality of the software we're making, both because pressure from peers pointing out issues will improve quality, and since people will use what they learn as users to make better decisions as developers. For Firefox, we have tests that generally avoid serious regressions like this one. Unfortunately B2G doesn't have good test coverage yet, which means that we have to fix serious regressions with backouts instead of preventing them from getting in the tree in the first place. That's unfortunate; we really should have better test coverage. But backing regressions out quickly is, now, the best chance we have to keep quality high enough that we can use the phone, and thus keep quality improving.
Comment 19•10 years ago
|
||
(In reply to Gina Yeh [:gyeh] [:ginayeh] from comment #17) > I don't know why we directly backout bug 989198 without asking any > information like ETA. Because I asked RyanVM to back out. Backing out should be the default action if some patch causes major issues. It is not a punishment as dbaron says.
Comment 20•10 years ago
|
||
Please verify that that this issue is fixed.
Flags: needinfo?(rpribble)
Keywords: verifyme
Comment 21•10 years ago
|
||
This issue is FIXED on the latest v2.2. Device: Flame 2.2 Master KK (319 MB) BuildID: 20141027040237 (full flash) Gaia: e91d99e4d96954f06383c00bb9d79598a697e310 Gecko: 8230834302c9 Gonk: 6e51d9216901d39d192d9e6dd86a5e15b0641a89 Version: 36.0a1 (2.2 Master) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Tapping the power button locks and unlocks the screen as expected.
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(rpribble) → needinfo?(ktucker)
Keywords: verifyme
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Comment 22•9 years ago
|
||
Clearing the blocking nom for 2.2? as this is already fixed/verified on that branch per the status flag
blocking-b2g: 2.2? → ---
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•