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)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.2 affected, b2g-master affected)

RESOLVED INVALID
Tracking Status
b2g-v2.2 --- affected
b2g-master --- affected

People

(Reporter: Marty, Unassigned)

References

()

Details

(Keywords: privacy, Whiteboard: [3.0-Daily-Testing])

Attachments

(1 file)

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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
NI on Component area owner for nomination and assignment.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(gchang)
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)
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.

Attachment

General

Created:
Updated:
Size: