Closed Bug 1034183 Opened 6 years ago Closed 6 years ago

After Disabling Lockscreen on Passcode Locked Device, Re-enabling will Reinstate Old Passcode

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v1.3 wontfix, b2g-v1.3T wontfix, b2g-v1.4 wontfix, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.0 S6 (18july)
Tracking Status
b2g-v1.3 --- wontfix
b2g-v1.3T --- wontfix
b2g-v1.4 --- wontfix
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: kglazko, Assigned: timdream, Mentored)

References

Details

(Keywords: feature, Whiteboard: [good first bug][p=1])

Attachments

(2 files)

STR:

- User has a passlock on phone
- User gets tired of passlock, disables lockscreen correctly (having to enter existing passlock).
- A year goes by, decides to re-enable. 
- Old passcode STILL exists, is forced onto device.

Expected: Re-enabling lockscreen would not preserve old passcode after lockscreen has been disabled.

Actual: It does. What if the user has no idea what the passcode is, after a year? This functionality also affects the usability of Find My Device.
Flags: needinfo?
Flags: needinfo? → needinfo?(firefoxos-ux-bugzilla)
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
This issue is present in 1.3, 1.4 and 2.0. What is the UX point of view?
Blocks: 1034176
blocking-b2g: --- → 2.0?
Flagging Omega to clarify expected behavior, but this seems like a bad bug and I'd block on it. 

Omega, if I have the wrong person, please change the flag to the appropriate person.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(ofeng)
@Jenny, please help on this, thanks! :)
Flags: needinfo?(ofeng) → needinfo?(jelee)
(In reply to kglazko from comment #0) 
> Expected: Re-enabling lockscreen would not preserve old passcode after
> lockscreen has been disabled.
> 
> Actual: It does. What if the user has no idea what the passcode is, after a
> year? This functionality also affects the usability of Find My Device.

Hello, since disabling lockscreen requires passcode, the actual result should be what you described. Thanks!
Flags: needinfo?(jelee)
Triage: backlog'ing since this is a feature. However we agree this an annoy issue.
blocking-b2g: 2.0? → backlog
Keywords: feature
Jenny,

I think the proper fix of this bug should be automatically disable the passcode lock when the user disables lock screen, so that when the user re-enable the lock screen, she/he must re-enable passcode (and enter the new passcode) to enable passcode lock.

Do you agree with this approach?
Flags: needinfo?(jeliu)
Modify needinfo flag to the correct Jenny. :)
Flags: needinfo?(jeliu) → needinfo?(jelee)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #6)
> Jenny,
> 
> I think the proper fix of this bug should be automatically disable the
> passcode lock when the user disables lock screen, so that when the user
> re-enable the lock screen, she/he must re-enable passcode (and enter the new
> passcode) to enable passcode lock.
> 
> Do you agree with this approach?

Yes, that's what I have in mind. To double confirm, the proper behavior is as follow:

Precondition: 
Passcode lock set up and turned on + screen lock turned on

Step: 
1. disable screen lock.
2. enter passcode lock, once complete, passcode would be disabled (so next time when user wants to enable passcode, they need to enter a new passcode).
3. screen lock and passcode both disabled.

Thank you!
Flags: needinfo?(jelee)
Arthur, is this a good first bug?
Flags: needinfo?(arthur.chen)
Mentor: arthur.chen
Component: Gaia::System::Lockscreen → Gaia::Settings
Flags: needinfo?(arthur.chen)
Whiteboard: [good first bug]
Hi, :timdream, :jennyliu this bug poses an immediate feature impact for Find My Device.
We usually don't take late feature requests, but this sounds easy and it can help me understand how settings works today. I have patch ready.
Assignee: nobody → timdream
Status: NEW → ASSIGNED
Whiteboard: [good first bug] → [good first bug][p=1]
Target Milestone: --- → 2.0 S6 (18july)
Comment on attachment 8452137 [details] [review]
mozilla-b2g:master PR#21477

I don't know how mocks are loaded but it seems that |window.navigator.mozSettings| is of different instance of |window.MockNavigatorSettings|!!
Attachment #8452137 - Flags: review?(arthur.chen)
Comment on attachment 8452137 [details] [review]
mozilla-b2g:master PR#21477

We used requirejs to load MockNavigatorSettings and it may not be the same instance and which depends on the implementation of the shim mechanism of requirejs. However, we should always use the instance returned from requirejs instead of the one under the window object.
Attachment #8452137 - Flags: review?(arthur.chen) → review+
master: https://github.com/mozilla-b2g/gaia/commit/5a202741458bd7200e547e62f8f969f73635b697
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
blocking-b2g: backlog → 2.0?
Comment on attachment 8452137 [details] [review]
mozilla-b2g:master PR#21477

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): feature
[User impact] if declined: impact to overall FMD feature 
[Testing completed]: test done locally and master since landing. Unit test in place.
[Risk to taking this patch] (and alternatives if risky): this is only a one-liner
[String changes made]: none.
Attachment #8452137 - Flags: approval-gaia-v2.0?
Late feature can't be blocked but the patch can be approved. Removing 2.0?
blocking-b2g: 2.0? → ---
Attachment #8452137 - Flags: approval-gaia-v2.0? → approval-gaia-v2.0+
s/Late feature can't be blocked/Late feature can't block the release/
Duplicate of this bug: 1078252
Attached video video
This issue has been verified successfully on Flame2.0 and 2.1
See attachment: Verify_1034183.MP4
Reproducing rate: 0/5
Reproducing steps:
Precondition: User has a passlock on phone
1. Launch Settings app –> Screen lock –> Disables lockscreen
2. Change system date to a year later. 
3. Screen lock –> Enable lockscreen
** Then it need to enter a new passcode

Flame2.0 build:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/ff1100ba2ab8
Build-ID        20141204000228
Version         32.0

Flame2.1 build:
Gaia-Rev        5655269098c7e82254e56933f1af05b4abe2a2f3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/86608c9389b5
Build-ID        20141204001201
Version         34.0
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.