1131795 - [Windows Management] The callscreen will time-out after 10 seconds when answering a phone call from the lockscreen; ignoring screen timeout settings.

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Joshua Mitchell (Inactive)]

Description:
 In Settings > Display you can set the duration of the screen timeout to stay on longer than default. This is respected in all aspects with the exception of the lockscreen, which timeouts after about 10 seconds with no input. When you receive a call when your device is 'asleep' you will technically be in front of the lockscreen so the call-screen will adopt the 10 second time-out of the lock-screen instead of the longer desired duration set by the user. This might affect a user that is trying to read contact information from the callscreen or information  on the notification bar. 

Repro Steps:
1) Update a Flame to 20150210010523
2) Tap the power button to turn the screen off
3) Receive a call
4) Answer the call
5) Observe the call-screen for 10 seconds

Actual:
The callscreen times out too quickly

Expected:
The call screen should respect the Settings > Display: timeout setting
-or-
Callscreen should never time-out

Environmental Variables:
Device: Flame 3.0
Build ID: 20150210010523
Gaia: 0cf517083f7eb5fc269e1236edba50534f65e3cd
Gecko: 2cb22c058add
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Repro frequency: 7/7
See attached: logcat unavailable as you can not capture one in front of the lockscreen (where this issue occurs)

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

This issue also occurs on 2.2 (v18d-1), 2.2 (v18d), 2.1 (v18d-1) and 2.0 (v18d-1)

Device: Flame 2.2 (KK - Nightly - Full Flash)
Build ID: 20150209002504
Gaia: e827781324cbde91d2434b388f5dead3303a85ee
Gecko: 0552759956d3
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 2.2 (KK - Nightly - Full-Flashed)
Build ID: 20150209002504
Gaia: e827781324cbde91d2434b388f5dead3303a85ee
Gecko: 0552759956d3
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 2.1 (KK - Nightly - Full-Flashed)
Build ID: 20150209001212
Gaia: 4a14bb118d55f3d15293c2ff55b7f29f9b0bfcdb
Gecko: 6cbe28d0bb8c
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0 (KK - Nightly - Full-Flashed)
Build ID: 20150209000204
Gaia: 2989f2b2bd12fcc0e9c017d2db766e76a55873b8
Gecko: ad3cf982b94d
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 32.0 (2.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 1

[Joshua Mitchell (Inactive)]

*edit -  This issue does NOT reproduce in 2.0

Comment 2

[Peter Bylenga [:PBylenga]]

Nominating initially for 2.2, 2.1 is affected as well though.

Functional regression of a core feature.

Requesting a window.

NI on component owner to take a look since 2.1 is affected.
NI on Martijn to check if we can get an automated test to cover this.

Comment 3

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I am seeing that Flame 2.0 DOES reproduce this issue (10/10 attempts) as listed in comment 0.  Not a regression.

Comment 4

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Variables for comment 3.

Environmental Variables:
Device: Flame 2.0
BuildID: 20150210182253
Gaia: 2989f2b2bd12fcc0e9c017d2db766e76a55873b8
Gecko: d47ec000ee85
Version: 32.0 (2.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 5

[Martijn Wargers (dead)]

(In reply to Peter Bylenga [:PBylenga] from comment #2)
> NI on Martijn to check if we can get an automated test to cover this.

We are switching over to marionetteJS framework to work on and write new tests. Currently, those don't support on device tests, which is what this one needs.
Currently, we're not supposed to write new Python gaia-ui tests anymore. Please raise this in our next roundtable meeting, if you have concerns about this.
Alternatively, we could leave this as thing-to-do as soon as marionetteJS is working on device and the features work to make a test like this.

Comment 6

[Gerry Chang [:gchang]]

NI windows management for this.

Comment 7

[Hermes Cheng (inactive after July 27, 2015)]

In my test, screen locked around 10 seconds even when I have set 1 minute as its timeout setting.
NI Alive.

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

This is by design; the screen timeout on lockscreen is 10sec. There is not a rule saying callscreen will override this behavior.

Comment 9

[Hermes Cheng (inactive after July 27, 2015)]

(In reply to Alive Kuo@Paris~2/17 [:alive][NEEDINFO!] from comment #8)
> This is by design; the screen timeout on lockscreen is 10sec. There is not a
> rule saying callscreen will override this behavior.

According to Alive's comment, mark this one as invalid. Please reopen it if you have any concern.

Comment 10

[Martijn Wargers (dead)]

Also see discussion in bug 933035.

Comment 11

[Martijn Wargers (dead)]

In bug 1169332 we added window.wrappedJSObject.ScreenManager.LOCKING_TIMEOUT = 9999, so the screen wouldn't turn black on lock screen there, either. I think it's not so important to get an automated test for this, that the screen turns black after 10s in lockscreen mode.
If you disagree, please add the in-qa-testsuite flag back.