Closed
Bug 1124867
Opened 10 years ago
Closed 10 years ago
[Privacy Panel][Remote Privacy Protection] Lock screen improperly respects Screen Timeout settings following an RPP function
Categories
(Firefox OS Graveyard :: Gaia, defect)
Tracking
(b2g-v2.2 affected, b2g-master affected)
RESOLVED
INVALID
People
(Reporter: Marty, Unassigned)
References
()
Details
(Keywords: privacy, Whiteboard: [3.0-Daily-Testing])
Attachments
(1 file)
21.24 KB,
text/plain
|
Details |
Description:
When the device locks itself following an RPP command, the screen will still respect the user setting in Display for the Screen Timeout. This means that after the device is locked, it will take at least 1 minute for the screen to shut off, and may not shut off at all if the user set the Screen Timeout to 'never.'
Ordinarily, the device will turn the screen off after 10 seconds whenever it is at the lock screen, regardless of the Screen Timeout setting.
Note: This issue only occurs if the device was unlocked before the RPP function is received. If the device was already locked, or if the user manually shuts off the screen with the Power Button, this issue will no longer occur.
Repro Steps:
1) Update a device to BuildID: 20150122010203
2) Open Settings and navigate to Privacy Panel.
3) Progress past the Guided Tour, and select Remote Privacy Protection
4) Configure a Passphrase and enable the RPP Lock function
5) Navigate to Settings > Display and configure the Screen Timeout to be '2 Minutes'
6) From a second device, send 'RPP lock <PASSPHRASE>' in an SMS to the DUT
7) Observe the time it takes for the screen to shut off
Actual:
Screen shuts off after 2 minutes, improperly respecting the Display settings
Expected:
Screen shuts off after 10 seconds, congruent with Lock Screen behavior under other circumstances.
Environmental Variables:
Device: Flame Master 3.0 (Full Flash)(319MB)
BuildID: 20150122010203
Gaia: 917b6c36717fddc6e71ffc1ec249633c8044c93c
Gecko: 34e2d2bd7ec4
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
Repro frequency: 5/5
See attached: video clip (URL), logcat
-------------------------------------------
This issue DOES occur on Flame 2.2.
Screen shuts off after 2 minutes, improperly respecting the Display settings
Environmental Variables:
Device: Flame 2.2 (Full Flash)(319MB)
BuildID: 20150122002808
Gaia: e4f9b5da3751798f9cc5d95f302c30722cc11fca
Gecko: 4a90da67661e
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
-------------------------------------------
This issue does NOT occur on Flame 2.1
Privacy Panel was not implemented on this branch.
Environmental Variables:
Device: Flame 2.1 (Full Flash)(319MB)
BuildID: 20150121001510
Gaia: 77c57eb8a985d5cbd34a597fb1b978ba6e205af6
Gecko: 4c28bb3be0c6
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 34.0 (2.1)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Comment 1•10 years ago
|
||
NI on Component area owner for nomination and assignment.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(gchang)
Comment 2•10 years ago
|
||
Because the device was unlocked before the RPP function is received, I'm not sure the device should follow the behavior of settings in Display or 10 seconds in lock screen.
This needs UX's help to determine which one is the correct behavior.
Flags: needinfo?(gchang) → needinfo?(jhuang)
Comment 3•10 years ago
|
||
I think the better way is to align the time all together, in case some people intent to set up time in specific second.
So I would suggest that no matter the phone is unlock or not, the screen timeout should be the same time as it display in settings app.
Flags: needinfo?(jhuang)
Closing this Bug as Juwei stated that this is a proper behaviour.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•