832706 - Support more granular time allowances in phone lock (e.g. after 5 seconds, after 15 seconds, after 30 seconds)

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Build Identifier: 20130116230203
Git commit info: 3c84fa2b74b3dbe591f0d4fbedbac9aac...

Jelly Bean supports automatically locking:

Immediately
5 seconds
15 seconds
30 seconds
1 minute
2 minutes
5 minutes
10 minutes
30 minutes

whereas Firefox OS only supports locking:

Immediately
After 1 minute
After 5 minutes
After 15 minutes
After 1 hour
After 4 hours

I like setting my phone to 5 or 15 seconds because sometimes I may inadvertently shut my phone screen by accidentally hitting the power button, and I don't want to re-hit my password again.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: patch v1

First patch to Gaia!

(I don't know how this is tested though, if tests are compulsory)

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

This patch adds 5, 15 and 30 second as well as 2, 10 and 30 minute delay options.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

On second thoughts, we really should decide how granular we want to be, instead of grabbing the options wholesale. How granular is too granular?

Or should we have an additional open ended option allowing people to input exactly how many seconds/minutes prior to phone lock?

Comment 4

[Fabien Cazenave [:kaze]]

Technically speaking the patch is fine, but I don’t know if we want *this* level of granularity. Requesting UX input on this.

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I'd like at least the option of 15 seconds, that was the original impetus for this bug - something less than a minute (e.g. 15 or 30 seconds) fits my use case.

Comment 6

[Josh Carpenter [:jcarpenter]]

(In reply to Fabien Cazenave [:kaze] from comment #4)
> Technically speaking the patch is fine, but I don’t know if we want *this*
> level of granularity. Requesting UX input on this.

Thanks for flagging, Kaze. From a UX standpoint I'm fine with this :) Good idea, Gary!

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

> Or should we have an additional open ended option allowing people to input
> exactly how many seconds/minutes prior to phone lock?

Josh, did you refer to the level of granularity in the patch, or this suggested level of granularity?

Comment 8

[Fabien Cazenave [:kaze]]

Comment on attachment 704289 [details] [diff] [review]
patch v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): n/a
User impact if declined: minimum time before phone lock is 1 min
Testing completed: manual
Risk to taking this patch (and alternatives if risky): low

Comment 9

[Josh Carpenter [:jcarpenter]]

(In reply to Gary Kwong [:gkw] from comment #7)
> > Or should we have an additional open ended option allowing people to input
> > exactly how many seconds/minutes prior to phone lock?
> 
> Josh, did you refer to the level of granularity in the patch, or this
> suggested level of granularity?

The patch, which I understand—per comment #2—bring our increments to:

* Immediately
* 5 sec
* 15 sec
* 30 sec
* 1 min
* 2 min
* 5 min
* 10 min
* 15 min
* 30 min
* 1 hour
* 4 hours

I question the need for 1 hour and 4 hours, to be honest, but *shrug*. I wouldn't overthink this. :) Let's try that out and see how it feels. We can easily revisit in future versions.

Comment 10

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Great, Josh, thank you!

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 704289 [details] [diff] [review]
patch v1

This doesn't even have a UX priority on it, so we're minusing for uplift, it can go ahead and bake on master - and will get into v1.1.0

Comment 12

[Lukas Blakk [:lsblakk] use ?needinfo]

Tracking-b2g19=20+ so this gets uplifted to v1-train once v1.0.1 has branched.

Comment 13

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I'm guessing this can land since 1.0.1 has likely branched:

https://wiki.mozilla.org/Release_Management/B2G_Landing

(please feel free to change this if this is not the case)

Comment 14

[John Ford [:jhford] CET/CEST Berlin Time]

master: 0ccdcb957c6cbcfeea453cfab0898e9988111c62

Alex, this bug is approval-gaia-v1- but tracking-b2g+.  Which takes precedence?

Comment 15

[John Ford [:jhford] CET/CEST Berlin Time]

Lukas, you set this to tracking-b2g:+, which means we should land on v1-train but set the fix's approval-gaia-v1:- 

Comments lead me to believe that we do want this on v1-train, but I'd like to be sure before I uplift it.

Comment 16

[Lukas Blakk [:lsblakk] use ?needinfo]

This was minused for approval prior to v1.0.1 branching, then tracked for v1-train so yes it can get into v1.1 now.

Comment 17

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Needs landing for v1.1.

Comment 18

[John Ford [:jhford] CET/CEST Berlin Time]

v1-train: 29bc13511b2d8aa65c53e34982179317aa919692

Comment 19

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Thanks all!

Comment 20

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Did this cause some test to fail?

https://travis-ci.org/mozilla-b2g/gaia/builds/5483759

(I have no idea what is going on)