Closed
Bug 1034183
Opened 10 years ago
Closed 10 years ago
After Disabling Lockscreen on Passcode Locked Device, Re-enabling will Reinstate Old Passcode
Categories
(Firefox OS Graveyard :: Gaia::Settings, defect)
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)
People
(Reporter: kglazko, Assigned: timdream, Mentored)
References
Details
(Keywords: feature, Whiteboard: [good first bug][p=1])
Attachments
(2 files)
46 bytes,
text/x-github-pull-request
|
arthurcc
:
review+
bajaj
:
approval-gaia-v2.0+
|
Details | Review |
1.68 MB,
video/mp4
|
Details |
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•10 years ago
|
Flags: needinfo?
Updated•10 years ago
|
Flags: needinfo? → needinfo?(firefoxos-ux-bugzilla)
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Comment 1•10 years ago
|
||
This issue is present in 1.3, 1.4 and 2.0. What is the UX point of view?
Updated•10 years ago
|
blocking-b2g: --- → 2.0?
Comment 2•10 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)
Comment 3•10 years ago
|
||
@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)
Assignee | ||
Comment 5•10 years ago
|
||
Triage: backlog'ing since this is a feature. However we agree this an annoy issue.
blocking-b2g: 2.0? → backlog
Keywords: feature
Assignee | ||
Comment 6•10 years ago
|
||
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•10 years ago
|
||
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)
Updated•10 years ago
|
Mentor: arthur.chen
Component: Gaia::System::Lockscreen → Gaia::Settings
Flags: needinfo?(arthur.chen)
Whiteboard: [good first bug]
Reporter | ||
Comment 10•10 years ago
|
||
Hi, :timdream, :jennyliu this bug poses an immediate feature impact for Find My Device.
Assignee | ||
Comment 11•10 years ago
|
||
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)
Assignee | ||
Comment 13•10 years ago
|
||
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 14•10 years ago
|
||
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+
Assignee | ||
Comment 15•10 years ago
|
||
master: https://github.com/mozilla-b2g/gaia/commit/5a202741458bd7200e547e62f8f969f73635b697
Updated•10 years ago
|
blocking-b2g: backlog → 2.0?
Assignee | ||
Comment 16•10 years ago
|
||
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?
Assignee | ||
Comment 17•10 years ago
|
||
Late feature can't be blocked but the patch can be approved. Removing 2.0?
blocking-b2g: 2.0? → ---
Updated•10 years ago
|
Attachment #8452137 -
Flags: approval-gaia-v2.0? → approval-gaia-v2.0+
Assignee | ||
Comment 18•10 years ago
|
||
s/Late feature can't be blocked/Late feature can't block the release/
Comment 19•10 years ago
|
||
v2.0: https://github.com/mozilla-b2g/gaia/commit/621eb9f7e0b56648d244106b2fc1331c32d40c3b
Comment 21•10 years ago
|
||
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
Updated•10 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•