Closed Bug 1044270 Opened 10 years ago Closed 10 years ago

[B2G][Flame][Lockscreen] Device locks faster than the screen timeout setting

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: AdamA, Unassigned)

References

()

Details

(Whiteboard: [2.0-flame-test-run-3])

Attachments

(1 file)

Attached file logcat.txt
After locking the screen once, the device will automatically lock in about 10 seconds even though the screen timeout is set to 1 minute.

Repro Steps:
1) Update a Flame to BuildID: 20140725000201
2) set screen timeout in settings to 1 minute
3) Using the power button, lock the screen
4) Unlock the screen
5) Observe amount of time it takes screen to timeout

Actual:
Screen timeouts after approximately 10 seconds

Expected:
It is expected that the screen timeouts after time set in the screen timeout menu

Environmental Variables:
Device: Flame 2.0 (319mb)
Build ID: 20140725000201
Gaia: 9b6d7357031f2412b18a2fb140d5c974842d4393
Gecko: fbb3b8be8f6c
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Keywords: power off, black screen

Repro frequency: 100%
See attached: logcat, video(http://youtu.be/dfCqFfWBuu4)

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

This issue also occurs in 2.1 Flame, 2.1 Buri, 2.0 Flame(512mb), 2.0 Buri, 1.4 Flame, and 1.4 Buri.

Environmental Variables:
Device: Flame Master (319mb)
Build ID: 20140725040205
Gaia: 3a06aa58245eaf848242d6d1497c1af536fffabd
Gecko: 6c0971104909
Version: 34.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0 (512mb)
Build ID: 20140725000201
Gaia: 9b6d7357031f2412b18a2fb140d5c974842d4393
Gecko: fbb3b8be8f6c
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Flame 1.4 (319mb)
Build ID: 20140725000205
Gaia: 6e4eaa5befce9c1812e07bcc78b2138645bdbe7a
Gecko: 300e058993ca
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Device: Buri Master
Build ID: 20140725040205
Gaia: 3a06aa58245eaf848242d6d1497c1af536fffabd
Gecko: 6c0971104909
Version: 34.0a1 (Master)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Buri 2.0
Build ID: 20140725000201
Gaia: 9b6d7357031f2412b18a2fb140d5c974842d4393
Gecko: fbb3b8be8f6c
Version: 32.0a2 (2.0)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Environmental Variables:
Device: Buri 1.4
Build ID: 20140725000205
Gaia: 6e4eaa5befce9c1812e07bcc78b2138645bdbe7a
Gecko: 300e058993ca
Version: 30.0 (1.4)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Actual:
Screen timeouts after approximately 10 seconds
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
[Blocking Requested - why for this release]:

This was a blocker before on 2.1 so nominating this to block 2.0 as well. This issue was resolved in bug 1028374 and has resurfaced.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
> After locking the screen once, the device will automatically lock in about 10 seconds even though the screen timeout is set to 1 minute.

In fact, the 10 seconds timeout is a spec since at least v1.2. The timeout is irrelevant with the screen timeout in Settings app, and it's hard coded as 10 seconds according to the requirement.

Please note this "bug" has been reported several times, and it's not a bug. If there is any opinion that the feature should be fixed, please NI UX team, thanks.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
blocking-b2g: 2.0? → ---
This test case is invalid because the timeout is irrelevant with the screen timeout in Settings app, and it's hard coded as 10 seconds.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(jthomas)
No need for a test case since here since this bug has been resolved as invalid.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(jthomas)
Flags: in-moztrap-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: