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

VERIFIED FIXED in Firefox OS v2.0

Status

VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: kglazko, Assigned: timdream, Mentored)

Tracking

({feature})

unspecified
2.0 S6 (18july)
ARM
Gonk (Firefox OS)
feature

Firefox Tracking Flags

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

Details

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

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

4 years ago
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?
status-b2g-v1.3: --- → affected
status-b2g-v1.4: --- → affected
status-b2g-v2.0: --- → affected
(Reporter)

Updated

4 years ago
Blocks: 1034176

Updated

4 years ago
blocking-b2g: --- → 2.0?

Comment 2

4 years ago
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)

Comment 4

4 years ago
(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)

Comment 7

4 years ago
Modify needinfo flag to the correct Jenny. :)
Flags: needinfo?(jeliu) → needinfo?(jelee)

Comment 8

4 years ago
(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]
(Reporter)

Comment 10

4 years ago
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
Last Resolved: 4 years ago
status-b2g-v2.1: --- → fixed
Resolution: --- → FIXED

Updated

4 years ago
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? → ---

Updated

4 years ago
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/
v2.0: https://github.com/mozilla-b2g/gaia/commit/621eb9f7e0b56648d244106b2fc1331c32d40c3b
status-b2g-v1.3: affected → wontfix
status-b2g-v1.3T: --- → wontfix
status-b2g-v1.4: affected → wontfix
status-b2g-v2.0: affected → fixed
Duplicate of this bug: 1078252
Created attachment 8532430 [details]
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
status-b2g-v2.0: fixed → verified
status-b2g-v2.1: fixed → verified
You need to log in before you can comment on or make changes to this bug.