1023218 - Do not automatically show the passcode when the screen is turned on

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Description

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Dogfooding the device with a passcode, it extremelly annoying every time I received a notification/sms.

The screen turns on, the passcode shows up, and the notifications are hidden, and so I need to hide the passcode. Read the notification. Maybe re-show the passcode to enter the phone.

This patch just get rid of the automatic showing of the passcode.

Comment 1

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: no.automatic.passcode.patch

Comment 2

[John Lu [:mnjul][Please NI or I'll miss]]

This particular behavior was decided in bug 867219 and I don't see why we should revert it (before debating with UX people, of course).

Comment 3

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to John Lu [:mnjul] @MoCoTaipei from comment #2)
> This particular behavior was decided in bug 867219 and I don't see why we
> should revert it (before debating with UX people, of course).

This particular behavior has likely be decided on a piece of paper. Which is fine, since this is what we all do -  UX, marketting, engineering, etc.

Now there is also stuff that happens when you actually use the phone :)

Do you dogfood the phone as your primary phone, with a passcode, on a daily basis ?

So here is the result of this behavior for me:
 - The phone is in my pocket
 - I receive a notification
 - I hear it, takes the phone

Expected:
 I can see the notification I just received

Actual result:
 The passcode is on my way, hiding all notifications. I need to close it, then read the notification, then bring it back to enter my passcode if I want to react.


Second behavior if I don't hear the notification.

 - the phone stays in my pocket with the screen on
 - in my pocket the phone hit the camera button

Expected result:
 - the camera app should never starts in my pocket

Actual result:
 - I get the phone out of my pocket, realize the camera app is opened, it has suck down my battery and I need to close it
 - Or I receive a notification, hear it, take the phone out of my pocket, realize the camera app is opened, hit home to go back to the lockscreen, dismiss the passcode, read my notification, bring back the passcode...

Same thing happens with the emergency dialer. I keep hitting keys of the emergency dialer from my pocket. And I heard it in the station, in meeting, and so on...


Now, I'm not saying I am a UX guy - so I will let the final decision to UX folks, but resolving a real issue as INVALID just because it is spec'ed as if seems strange to me.

Also the name of the bug you mentioned seems like the decision was made to make user life simpler. As a user, my life is definitively not simpler with this feature, as the phone may start in 5 modes (5 because there is also a bug and sometimes the passcode is not shown! \o/)

 - The passcode is not here when the phone start
 - The passcode is here when the phone start
 - The passcode is here when the phone start and some numbers have already been entered
 - The camera app is here when the phone start
 - The emergency dialer is here when the phone startns

Then in order to open the phone I may need:
 - One action (best case scenario - everything is as expected, just need to enter the passcode)
 - 2 actions if I have the emergency dialer / camera opened (dismiss the app, type the passcode)
 - 3 actions if I have a notification (remove the passcode, show the passcode, type the passcode)
 - 4 actions if I have the emergency dialer / camera opened and a notification (dismiss the app, dismiss the passcode, show the passcode, type the passcode)
 - 5,6 or 7 actions if I have the emergency dialer / camera opened, a notification and wrong numbers in the passcode (1, 2 or 3 wrong numbers). (dismiss the app, delete char 1, delete char 2, delete char 3, dismiss the passcode, show the passcode, type my passcode)

So it's not very funny and a bit confusing :)

Jaime, is there anything we can do on the UX side do you believe this is a nice behavior for the user ;) ?

Comment 4

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Vivien, you may ni? the wrong person.

I am not Jaime and maybe you have to ni? the right one again haha

Comment 5

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to EJ Chen [:eragonj][:小龍哥] from comment #4)
> Vivien, you may ni? the wrong person.
> 
> I am not Jaime and maybe you have to ni? the right one again haha

Oups! :)

Comment 6

[Stephany Wilkes]

Vivien, the UX team does dogfood the phone as our primary phones, many of us with a passcode, on a daily basis. We each have secondary phones for daily multi-build flashing. 

I am flagging Francis while several other UX folks are out of the office this week. Francis, I think this is actually more about notifications than lockscreen.

Comment 7

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I am sided with Vivien too because having the passcode panel shown when the screen on actually defeat the purpose of lock screen handle (prevent accidental unlock of the phone in your pocket).

Many of the people set their passcode with four equal digits like 0000 so to unlock faster.

Comment 8

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Triage: still waiting for UX to respond. Keeping 2.0?

Comment 9

[Rob MacDonald [:robmac]]

This was actually a partner requirement that was agreed to over a year ago. 

Wayne, can you confirm this requirement is still valid? If not, UX would prefer to take the approach of the patch for the reasons Vivien described above.

Comment 10

[Wayne Chang [:wchang]]

Rob, I believe back when it's requested we weren't getting many, if any, notifications on lockscreen but it's likely the request would persist. To match the experience on Android is it possible to get the best of both sides?

i.e. on screen on event, if there is a notification then show notification, for any further interaction bring up the PIN entry pad. If there is no notification present then show the PIN entry pad directly?

Comment 11

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Wayne Chang [:wchang] from comment #10)
> Rob, I believe back when it's requested we weren't getting many, if any,
> notifications on lockscreen but it's likely the request would persist. To
> match the experience on Android is it possible to get the best of both sides?
> 
> i.e. on screen on event, if there is a notification then show notification,
> for any further interaction bring up the PIN entry pad. If there is no
> notification present then show the PIN entry pad directly?

Waine, please re-read what happens in https://bugzilla.mozilla.org/show_bug.cgi?id=1023218#c3

The phone keeps beeing turned on in my pocket, with or without notifications and I end up into the situation where I need to do multiple actions to finally unlock the phone, with or without notifications. It also consumes more battery as the camera app starts, etc...

Also I believe on which Android you have handy. The one I have handy with a passcode turned on, starts with a black empty text field, and I need to tap it in order to show the keyboard. Still one action before accessing the keypad.

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Triage: waiting for a conclusion to this bug. Keeping 2.0?

Comment 13

[Bruce Huang [:bhuang] (inactive)]

Considering our old unlock behavior involved multiple actions (slide up, tap), perhaps the partner requirement no longer applies.  With the new behavior we've really made it easier to get to the unlock action.  If we can move towards the behavior in the patch then we have the option to do more with the notifications as well in the future.
Let's move forward with this and communicate to the partner if needed.

Comment 14

[bhavana bajaj [:bajaj]]

I guess this could be annoying but something we would not hold the release for. Feel free to renom if there is disagreement here explaining why. Else seek approval if this is ready to go-in.

Comment 15

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to bhavana bajaj [:bajaj] [NOT reading Bugmail, needInfo please] from comment #14)
> I guess this could be annoying but something we would not hold the release
> for. Feel free to renom if there is disagreement here explaining why. Else
> seek approval if this is ready to go-in.

Renoming.

It's not particularly a big bug in terms of performance, nor a crash of the phone. But this is the first thing you have in your face everytime you turn on the phone, and the only user workaround for it is disabling the access security check of the phone.

It gives a particular bad feeling just because you get the phone out of your pocket, without having yet started to use it...

Comment 16

[Rob MacDonald [:robmac]]

(In reply to Bruce Huang [:bhuang] <[e-mail]> from comment #13)
> Considering our old unlock behavior involved multiple actions (slide up,
> tap), perhaps the partner requirement no longer applies.  With the new
> behavior we've really made it easier to get to the unlock action.  If we can
> move towards the behavior in the patch then we have the option to do more
> with the notifications as well in the future.
> Let's move forward with this and communicate to the partner if needed.

Assuming the partner requirement no longer applies, the I'm a fan of Vivien's proposal. Vivien, I'm having problems reviewing the patch but I understand you're at the work week so let's review it then.

Comment 17

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Rob MacDonald [:robmac] from comment #16)
> (In reply to Bruce Huang [:bhuang] <[e-mail]> from comment #13)
> > Considering our old unlock behavior involved multiple actions (slide up,
> > tap), perhaps the partner requirement no longer applies.  With the new
> > behavior we've really made it easier to get to the unlock action.  If we can
> > move towards the behavior in the patch then we have the option to do more
> > with the notifications as well in the future.
> > Let's move forward with this and communicate to the partner if needed.
> 
> Assuming the partner requirement no longer applies, the I'm a fan of
> Vivien's proposal. Vivien, I'm having problems reviewing the patch but I
> understand you're at the work week so let's review it then.

For some reasons I can't attend the work week. The patch basically does not open the passcode when the screen is turned on.

Comment 18

[Rob MacDonald [:robmac]]

Etienne helped me with the patch today and it looks great. Although by strict definition this isn't a blocker, this would be a big UX improvement for the 2.0 release. Considering Etienne and Vivien believe this is a low risk patch, and Bruce has already given his ok from the requirements perspective, I would recommend uplift for 2.0.

Comment 19

[Tony Chung [:tchung]]

wouldnt block a release for this.  but this can be flagged for uplift approval when the patch has landed

Comment 20

[Bruce Huang [:bhuang] (inactive)]

Let's go for uplift approval when ready.

Comment 21

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

jlu, do you mind reviewing the patch now that UX is fine with the change ?

Comment 23

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Migrate flags from bug 1016843.

Comment 24

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Actually feature-b2g should be removed since this is not a planned feature for 2.1.

But these flag does not planing this bug from being landed and show up on 2.1, and even uplift to 2.0.

Comment 25

[John Lu [:mnjul][Please NI or I'll miss]]

Comment on attachment 8437633 [details] [diff] [review]
no.automatic.passcode.patch

Review of attachment 8437633 [details] [diff] [review]:
-----------------------------------------------------------------

Patch looks great and works as intended. Thanks for it :)

Comment 26

[Rob MacDonald [:robmac]]

Comment on attachment 8437633 [details] [diff] [review]
no.automatic.passcode.patch

+'ing based on my earlier comment and the review on Etienne's build during the work week.

Comment 27

[Jordan Lund (:jlund)]

I was on PTO and just noticed the need-info. Looks like you meant [e-mail] :)

Comment 28

[Greg Weng [:snowmantw][:gweng][:λ]]

I've implemented the patch in Bug 1043821 for master, which is necessary to stabilize the minor visual regression which need to be solved with a refactoring work. And I've discussed with John. So if we can wait, this bug would be resolved by Bug 1043821, that is also a LockScreen bug.

Comment 29

[bhavana bajaj [:bajaj]]

This still does not have an approval request for 2.0 and at this point we only want critical bugs(blockers) to land on 2.0 so this has missed the ship, lets get this improved in 2.1.

Comment 30

[Greg Weng [:snowmantw][:gweng][:λ]]

Oh, I've forgotten that the Bug 1043821 got resolved, so this bug now should be closed, too. But I don't know whether in this case it's a duplicated or fixed bug, so I flag it as fixed (by the Bug 1043821).