Closed Bug 949034 Opened 6 years ago Closed 6 years ago

[B2G][Lockscreen]Lock screen still appears when re-opening the phone after switching it off if a passcode has been created.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:1.3+, b2g-v1.3 fixed)

RESOLVED FIXED
1.3 C1/1.4 S1(20dec)
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed

People

(Reporter: astole, Assigned: neeraj_kumar)

References

Details

(Keywords: regression, Whiteboard: burirun1.3-1)

Attachments

(2 files)

2.30 MB, video/3gpp
Details
46 bytes, text/x-github-pull-request
arthurcc
: review+
alive
: review+
Details | Review
Attached video Video
After creating a passcode and turning the Lock screen option off, the user still receives a Lock screen and must enter the passcode to unlock the phone.

Repro Steps:
1) Updated Buri to BuildID: 20131211004003
2) Navigate to Settings > Screen lock.
3) Turn on Passcode lock
4) Create a new passcode
5) Turn off Lock screen
6) Exit phone > Re-open phone
7) Observe that a passcode is required.

Actual:
Passcode is required when Lock screen option is turned off.

Expected:
No passcode is required if the Lock screen option is turned off.

Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20131211004003
Gaia: 7a2ccae2a546ac4d981d250272dafa630c926422
Gecko: 6bb84d0bc170
Version: 28.0a2
Firmware Version: V1.2_20131115

Notes:
Lock screen option works correctly if a pass code has not been created.

Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/2552/
See attached: Video
This does not repro in Buri V1.2
No passcode is required if the Lock screen option is turned off after a passcode is created.

Environmental Variables:
Device: Buri v1.2 Mozilla RIL
BuildID: 20131210004008
Gaia: 3bede56043379283cb0f6673730f91be88018d13
Gecko: e535d93d88ad
Version: 26.0
Firmware Version: V1.2_20131115
QA Contact: nkhristoforov
The regression window occurs from 11-14 to 11-15. I noticed that before the 11-15 build, the user is not prompted for the lock screen passcode when turning off the lockscreen. On the 11-15 where the bug is introduced, the user is asked for the passcode after turning off the lockscreen.

Last Working Build:
Device: Buri v1.3 Moz RIL
BuildID: 20131114143149
Gaia: 4ea5adac92d6a9ab035e708e941d50be0d670da2
Gecko: 7b014f0f3b03
Version: 28.0a1

First Broken Build:
Device: Buri v1.3 Moz RIL
BuildID: 20131115040200
Gaia: ac42cb33f21b3f13595432c965f44615daae2225
Gecko: b2fab608772f
Version: 28.0a1
blocking-b2g: --- → 1.3?
Triage: regression.

Greg, could you help? Thanks!
blocking-b2g: 1.3? → 1.3+
Flags: needinfo?(gweng)
The regressed bug as bug 811624.

Neeraj, as the original author of the feature, would you like to provide a follow-up fix?
Depends on: 811624
Flags: needinfo?(gweng) → needinfo?(neeraj_kumar)
Component: Gaia::System::Lockscreen → Gaia::Settings
Hello Tim,

Figured out the issue. Lock screen is validating the value of lockscreen.passcode instead of lockscreen.enabled.

Patch is coming soon. 

Thanks.
Flags: needinfo?(neeraj_kumar)
(In reply to Neeraj from comment #5)
> Hello Tim,
> 
> Figured out the issue. Lock screen is validating the value of
> lockscreen.passcode instead of lockscreen.enabled.
> 
> Patch is coming soon. 
> 
> Thanks.

Neeraj,

Thanks! Please make sure to submit unit tests to LockScreen to ensure it respond to settings appropriately and ensure no one will damage your work.
Hi Neeraj,

One more thing, sorry; this bug is marked as 1.3+, which means we require this bug to be fixed before shipping the FxOS v1.3 release -- for bugs with blocking status, we kindly ask owner of the bug (you) to set a "Target Milestone" and make yourself available to fix the bug within the time frame. Please do so and select a future date between 1.3 C1 to 1.3 C6 (please avoid C5 or C6 coz QA would like to caught possible regression earlier). If you happen to be unavailable under the schedule, I can redirect the bug to someone else.

Thanks!
Assignee: nobody → neeraj_kumar
Flags: needinfo?(neeraj_kumar)
Hello Arthur,

Please help me by reviewing this patch (https://github.com/mozilla-b2g/gaia/pull/14646). 

Thanks in advance :)
Attachment #8347195 - Flags: review?(arthur.chen)
Flags: needinfo?(neeraj_kumar)
Target Milestone: --- → 1.3 C1/1.4 S1(20dec)
Comment on attachment 8347195 [details] [review]
Proposed patch for this bug.

Flag Alive for the system app.
Attachment #8347195 - Flags: review?(alive)
Comment on attachment 8347195 [details] [review]
Proposed patch for this bug.

Neeraj, thanks for the quick patch! r=me for the settings part with the nit addressed.
Attachment #8347195 - Flags: review?(arthur.chen) → review+
Comment on attachment 8347195 [details] [review]
Proposed patch for this bug.

Make sense I wonder why we don't have this bug before...
Attachment #8347195 - Flags: review?(alive) → review+
Neeraj, please rebase your pull request so people could land it for you.


Also removing "regression" from keyword -- according to others this does not count as a regression but rather a follow-up.
Flags: needinfo?(neeraj_kumar)
Keywords: regression
Hello Tim,

I have rebased this PR.

Please let me know if you require anything else from my side :)

Regards,
Flags: needinfo?(neeraj_kumar)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #12)
> Neeraj, please rebase your pull request so people could land it for you.
> 
> 
> Also removing "regression" from keyword -- according to others this does not
> count as a regression but rather a follow-up.

That still counts as a regression actually - a followup commonly can focus on resolving a regression from a landing, which is what's present here. We proved this is a regression in the above regression window in comment 2 - we know this worked previously.
Keywords: regression
Neeraj, the pull request is still not rebased. I still see gray button with "We can’t automatically merge this pull request." on Github in https://github.com/mozilla-b2g/gaia/pull/14646.


(In reply to Jason Smith [:jsmith] from comment #14)
> That still counts as a regression actually - a followup commonly can focus
> on resolving a regression from a landing, which is what's present here. We
> proved this is a regression in the above regression window in comment 2 - we
> know this worked previously.

Sure.
Flags: needinfo?(neeraj_kumar)
Hello Tim,

Thanks for correcting me , my mistake. I have rebased this PR now. Please verify it and let me know if it works :)
Flags: needinfo?(neeraj_kumar)
The patch looks alright.

I tried to land the patch but Travis failed to give it a green/red. Will try tomorrow.
Uplifted 11e24c6988fe586f65ce6a7ad29783046ad44254 to:
v1.3: 1430007cc20e8eb1e68ff161c742233c173e397f
You need to log in before you can comment on or make changes to this bug.