Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Description • 11 years ago

Currently it only unlock the phone when user pull the handle to the end, but Rob feel the timing is too early. We should unlock it only after the user's finger leave the screen, because the user may regret to unlock it while his/her finger is still on the device.

	Al Tsai [:atsai]
	Comment 2 • 11 years ago

If you turn the screen off by power key before unlock, the phone will automatically unlock itself next time you press power key to the lock screen.

STR:
1. Turn on the lock screen feature in settings app (It should be on by default)
2. Press the power key to turn off the screen
3. Press the power key again to turn on the screen
4. Drag the blue ball to unlock screen but hold it still and do not release
5. Press the power key to turn off the screen
6. Press the power key to turn on the screen

Expected Result: 
6. The screen is locked

Actual Result:
6. The screen is unlocked

[Environment]
Gaia:     7b6147372cbf560744a02be50e0a862a825caef6
Gecko:    http://hg.mozilla.org/releases/mozilla-aurora/rev/63a505ec015c
BuildID   20130922004001
Version   26.0a2

	Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Comment 3 • 11 years ago

I can't get it why these two bugs are duplicated: this bug focus on the timing to unlock after the user pull the handle to the end, and not concerns the behavior affects the lockscreen.

BTW, does the step 4. in STR means you drag the handle but not to the end? I can't reproduce the symptom you had mentioned. The screen will keep locked even after I followed the step 5 & 6.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 4 • 11 years ago

Blocking, must fix, Greg, it seems you have already working on this right?

	Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Comment 5 • 11 years ago

Yes, I've a almost finished version now. Of course it need UX's opinion. I'll need info Patrick while it's done.

	Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Comment 7 • 11 years ago

Comment on attachment 811805 [details]
Patch

Implement the requirement and fixes some names.
I'll keep working on the Bug 919858 which depends on this.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 8 • 11 years ago

Comment on attachment 811805 [details]
Patch

Please make sure the test passes to ensure no one is using variables you have renamed.

	Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Comment 9 • 11 years ago

I still can't close this bug due to the duplication problem.
I need info from Al to see how the bug he commented duplicated on this one.

master: https://github.com/mozilla-b2g/gaia/commit/e06fb8c775fdd0fdcb2e491472df95cbb3a88e58

	Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Comment 10 • 11 years ago

After a offline discussion, Al and I decided to reopen the Bug 919888 and close this bug.

	James Lal [:lightsofapollo]
	Comment 11 • 11 years ago

I was not able to uplift this bug to v1.2.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1.2, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1.2
  git cherry-pick -x -m1 e06fb8c775fdd0fdcb2e491472df95cbb3a88e58
  <RESOLVE MERGE CONFLICTS>
  git commit

	Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Comment 12 • 11 years ago

(In reply to James Lal [:lightsofapollo] from comment #11)
> I was not able to uplift this bug to v1.2.  If this bug has dependencies
> which are not marked in this bug, please comment on this bug.  If this bug
> depends on patches that aren't approved for v1.2, we need to re-evaluate the
> approval.  Otherwise, if this is just a merge conflict, you might be able to
> resolve it with:
> 
>   git checkout v1.2
>   git cherry-pick -x -m1 e06fb8c775fdd0fdcb2e491472df95cbb3a88e58
>   <RESOLVE MERGE CONFLICTS>
>   git commit

I've found the conflicts are from the Bug 917689 and Bug 903924, and the Bug 903924 should be tagged with koi+ (my fault).

The problem is that Bug 917689 is not a koi+ bug (I tagged it koi? but then be cancelled), due to it only affects FirefoxNightly on desktop. However it's important because I can't test the whole lockscreen on one of my major developing machine, and others may encounter the same issue.

Now I've solved the conflicts on my local branch as you mentioned, but I'm afraid that I don't know what should I do now. Maybe the Bug 917689 should be tagged with koi+ again?

	James Lal [:lightsofapollo]
	Comment 13 • 11 years ago

In the past when we had bugs that blocked a koi+ bug we (generally) uplifted it too... If its not insanely risky (or is only functional on Firefox proper) we should just uplift all those bugs.

	Greg Weng [:snowmantw][:gweng][:λ] Assignee
	Comment 14 • 11 years ago

(In reply to James Lal [:lightsofapollo] from comment #13)
> In the past when we had bugs that blocked a koi+ bug we (generally) uplifted
> it too... If its not insanely risky (or is only functional on Firefox
> proper) we should just uplift all those bugs.

I've tagged the Bug 903924 as koi?, but don't whether Bug 917689 should tag it as well.

	John Ford [:jhford] CET/CEST Berlin Time
	Comment 15 • 11 years ago

Greg, please make sure that you set flags for branch landings when you do them

v1.2: https://github.com/snowmantw/gaia/commit/a4fc369d82cfcd91a88198fe4b901e45c4a12a61

	sarsenyev
	Comment 16 • 11 years ago

After the fix is landed the issue no longer reproduces on Buri 1.2 COM RIL
The device is unlocking only when a user releases the handle

Device: Biri 1.2 COM RIL
BuildID: 20131108004004
Gaia: 4cf40fb30c7b8380ea83ed0d4efe043b8b81737f
Gecko: a886c641a306
Version: 26.0
Firmware Version: US_20131104