Closed Bug 1084530 Opened 10 years ago Closed 10 years ago

[Lockscreen] The device can fall asleep too quickly after dialing the last digit to an emergency number

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: KTucker, Assigned: gweng)

References

()

Details

(Keywords: regression, Whiteboard: [2.1-flame-test-run-3], )

Attachments

(2 files)

Description:
If the user dials 14 digits, erases those digits and then dials a 3 digit emergency number, they will notice the device will fall asleep too quickly after tapping that last digit. 

Prerequisite: Enable a passcode on the device. 

Repro Steps:
1) Updated Flame to Build ID: 20141015001201
2) Lock the device.
3) Wake the phone back up and slide to unlock.
4) Tap on "Emergency Call".
5) Dial 14 "1"s and then erase them. 
6) Dial a 3 digit emergency number and then pause a second before tapping call.

Actual:
The device will go to sleep.  

Expected:
The device should not go asleep so quickly after the user's last touch input. 

Environmental Variables
Device: Flame 2.1(KK)(319mb)(Full Flash)
Build ID: 20141015001201
Gecko: https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/4853208cb48a
Gaia: 379ea4c9dd6d3f8ca2f79ce59c15f6afe6e557c3
Platform Version: 34.0
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Repro frequency: 100%
Link to failed test case: Found during exploratory testing. 
See attached: video clip, logcat
Youtube: http://youtu.be/klOy7LkZYTM
This issue also occurs on the Flame 2.2. 

If the user dials 14 digits, erases those digits and then dials an emergency number, the device will fall asleep quickly after dialing the last digit.

Flame 2.2 

Device: Flame 2.2 Master KK (319mb) (Full Flash)
BuildID: 20141017040208
Gaia: abef62c0623e5504a97b4fd411e879a67b285b52
Gecko: ae1dfa192faf
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 36.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

------------------------------------------------------------------------

This issue does not occur on the Flame 2.0

The device does not fall asleep when the user pauses for a second after dialing and erasing 14 digits.

Flame 2.0

Device: Flame 2.0 KK (319mb) (Full Flash)
BuildID: 20141017000203
Gaia: 9c7dec14e058efef81f2267b724dad0850fc07e4
Gecko: c17df9fe087d
Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
[Blocking Requested - why for this release]: Device falling asleep during emergency call
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Contact: pcheng
b2g-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20140824235254
Gaia: 5fae8a02bc31d28a4a76371bd9b0c8ef98a4b4f4
Gecko: e8efd2cf56e8
Version: 34.0a1
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20140825011754
Gaia: c36879d1d2644b5e059ef06aa855def460f8e08f
Gecko: 42091f9dd02f
Version: 34.0a1
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First Broken Gaia & Last Working Gecko - issue DOES repro
Gaia: c36879d1d2644b5e059ef06aa855def460f8e08f
Gecko: e8efd2cf56e8

First Broken Gecko & Last Working Gaia - issue does NOT repro
Gaia: 5fae8a02bc31d28a4a76371bd9b0c8ef98a4b4f4
Gecko: 42091f9dd02f

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/5fae8a02bc31d28a4a76371bd9b0c8ef98a4b4f4...c36879d1d2644b5e059ef06aa855def460f8e08f

Caused by Bug 1043892.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
possibly caused by Bug 1043892 - can you take a look Greg?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(gweng)
I don't think it's related to Bug 1043892, although regression finding shows that. I think the real root cause is related to the default 10 secs that let ScreenManager forcibly shut the screen down in LockScreen mode, while Emergency app is stocking onto the LockScreen, the mode remains true for the manager. I would try it later to see if this assumption is true. Thanks for reporting.
Flags: needinfo?(gweng)
Yes, I think I fixed it without touching any code of the suspicious regression bug, and I still not sure if this is a regression since I didn't bisect it. Anyway, my patch fixed the behavior, by making the screen keep light if there is a secure app in the foreground. At least from the video this is what I thought I should fix. If you want, you can pick the patch to verify if the symptom is what I fixed, and change the title (it seems *irrelevant* to emergency app, but the secure app; so I suggest to change the title to something like "Screen fall asleep while secure app is on").

BTW, I think we should or already have UX spec about this, and the 10 seconds hard-coded timeout of LockScreen. Should we fix the spec, if my patch is a reasonable solution?
Attached file Patch
Attachment #8507330 - Flags: review?(alive)
Comment on attachment 8507330 [details] [review]
Patch

LGTM
Attachment #8507330 - Flags: review?(alive) → review+
Triage: regression blocking
blocking-b2g: 2.1? → 2.1+
Assignee: nobody → gweng
The patch only failed with intermittent tests:

https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=2d2d7b2057f9

And the patch is totally irrelevant with Gallery app and even LockScreen. So I would submit a patch for v2.1 and land the master version.
Attached file Patch v2.1
Comment on attachment 8510830 [details] [review]
Patch v2.1

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): The ScreenManager doesn't care the Secure apps, and we deprecated some legacy events during refactoring
[User impact] if declined: Error occurs 
[Testing completed]: Gaia-Try on v2.1 failed only with intermittent errors and one serious error caused by Bug 1082071, which I've confirmed the root cause and NI the author.
[Risk to taking this patch] (and alternatives if risky): No
[String changes made]: No
Attachment #8510830 - Flags: approval-gaia-v2.1?(fabrice)
master: https://github.com/mozilla-b2g/gaia/commit/ec624ed592169227c522ff9f096f200fe9dfd336
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Attachment #8510830 - Flags: approval-gaia-v2.1?(fabrice) → approval-gaia-v2.1+
Issue is verified fixed in Flame 2.1, 2.2 (Full Flash, nightly, 319 MB memory). 

Actual Results: Phone behaves correctly at the Emergency Call screen (does not lock prematurely). 

Device: Flame 2.1
BuildID: 20141029001202
Gaia: eb0aab0f13c78c7ac378ad860e865c4b6eaf669f
Gecko: 318019f80a8e
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.2
BuildID: 20141029040208
Gaia: 35e87ac4324f0f3abd93dcc70d61c9f37256a0f5
Gecko: 7e3c85754d32
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: