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)

ARM
Gonk (Firefox OS)
defect
Not set
normal

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
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?]
Flags: needinfo?(pbylenga)
Keywords: smoketest
[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)
Workaround:
The user can wake up the phone with a long press of the power button.
Workaround:
The user can wake up the phone with a long press of the power button.
Workaround:
The phone can be woken up with a long press of the power button.
QA Contact: jmercado
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)
With this new pre-requisites this isn't a smoke test blocker although still a critical regression.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: smoketest
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)
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
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.
Tzu-Lin, thanks for your detailed information. I'll take a look at it and update my observations here soon!
Flags: needinfo?(gyeh)
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.
Component: Gaia::System::Lockscreen → DOM
Product: Firefox OS → Core
Assignee: nobody → gyeh
Please backout bug 989198 then, and fix the issues in that bug (unless you can _quickly_ fix the issues in this bug).
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
(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.
(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.
Please verify that that this issue is fixed.
Flags: needinfo?(rpribble)
Keywords: verifyme
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
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Clearing the blocking nom for 2.2? as this is already fixed/verified on that branch per the status flag
blocking-b2g: 2.2? → ---
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.