Closed Bug 1034183 Opened 6 years ago Closed 6 years ago
After Disabling Lockscreen on Passcode Locked Device, Re-enabling will Reinstate Old Passcode
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? → 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?
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!
Triage: backlog'ing since this is a feature. However we agree this an annoy issue.
blocking-b2g: 2.0? → backlog
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?
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!
Arthur, is this a good first bug?
Component: Gaia::System::Lockscreen → Gaia::Settings
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+
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/
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
You need to log in before you can comment on or make changes to this bug.