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

RESOLVED FIXED

Status

Firefox OS
Gaia::System::Lockscreen
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: vingtetun, Unassigned)

Tracking

unspecified

Firefox Tracking Flags

(blocking-b2g:-, ux-b2g:2.1)

Details

(Whiteboard: [p=1])

Attachments

(1 attachment)

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.
Created attachment 8437633 [details] [diff] [review]
no.automatic.passcode.patch
Attachment #8437633 - Flags: review?(jlu)
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).
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
(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 ;) ?
Status: RESOLVED → REOPENED
Flags: needinfo?(ejchen)
Resolution: INVALID → ---
Vivien, you may ni? the wrong person.

I am not Jaime and maybe you have to ni? the right one again haha
Flags: needinfo?(ejchen)
(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! :)
Flags: needinfo?(jachen)
blocking-b2g: --- → 2.0?
Status: REOPENED → NEW
Flags: needinfo?(firefoxos-ux-bugzilla)

Comment 6

4 years ago
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.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(fdjabri)

Updated

4 years ago
Attachment #8437633 - Flags: ui-review?(rmacdonald)
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.
Triage: still waiting for UX to respond. Keeping 2.0?
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.
Flags: needinfo?(wchang)
Flags: needinfo?(jachen)
Flags: needinfo?(fdjabri)
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?
Flags: needinfo?(wchang) → needinfo?(rmacdonald)
(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.
Triage: waiting for a conclusion to this bug. Keeping 2.0?
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.
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.
blocking-b2g: 2.0? → -
(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...
blocking-b2g: - → 2.0?
(In reply to Bruce Huang [:bhuang] <bhuang@mozilla.com> 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.
Flags: needinfo?(rmacdonald)
(In reply to Rob MacDonald [:robmac] from comment #16)
> (In reply to Bruce Huang [:bhuang] <bhuang@mozilla.com> 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.
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.
Flags: needinfo?(bhuang)
Flags: needinfo?(bbajaj)
Flags: needinfo?(21)
wouldnt block a release for this.  but this can be flagged for uplift approval when the patch has landed
blocking-b2g: 2.0? → -
Let's go for uplift approval when ready.
Flags: needinfo?(bhuang)
jlu, do you mind reviewing the patch now that UX is fine with the change ?
Flags: needinfo?(21) → needinfo?(jlund)
Duplicate of this bug: 1016843
Migrate flags from bug 1016843.
feature-b2g: --- → 2.1
ux-b2g: --- → 2.1
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.
feature-b2g: 2.1 → ---
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 :)
Attachment #8437633 - Flags: review?(jlu) → review+
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.
Attachment #8437633 - Flags: ui-review?(rmacdonald) → ui-review+
I was on PTO and just noticed the need-info. Looks like you meant jlu@mozilla.com :)
Flags: needinfo?(jlund)
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.
Whiteboard: [p=1]
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.
Flags: needinfo?(bbajaj)
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).
Status: NEW → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.