[FTE] After entering wrong PIN code 3 times on start-up there is no way to enter the PUK code (device lockup)

VERIFIED FIXED in B2G C4 (2jan on)

Status

Firefox OS
Gaia::First Time Experience
P1
blocker
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: whimboo, Assigned: fcampo)

Tracking

({late-l10n, unagi})

unspecified
B2G C4 (2jan on)
late-l10n, unagi

Firefox Tracking Flags

(blocking-basecamp:+)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
When you enter the wrong PIN 3 times on startup there is no chance to enter the existent PUK code.

As given by bug 816150 there is no way to dismiss the window on start-up. That means if you enter the wrong PIN three times in a row, you are not able anymore to get it unlocked with your phone. Another phone has to be used to do that.

This sounds like a blocker for me.

Updated

5 years ago
Component: General → Gaia::System::Lockscreen
QA Contact: atsai

Updated

5 years ago
Component: Gaia::System::Lockscreen → Gaia::System
QA Contact: atsai
This should be definitely a blocker for certifying the device.

If the SIM Card is in locked status because of the maximum number of tries to enter the PIN has been reached, no option to enter the PIN should be offered. I see two options here:

1/ Show an screen to allow user to enter the PUK (instead of the PIN one). We should think on whether we allow user to skip this step or not (I would say yes).

2/ Do not offer any PIN or PUK screen and start up the phone as if no SIM card was inserted. User could go manually to settings to enter the PUK.
Flags: needinfo?(hello)

Updated

5 years ago
Flags: needinfo?(jcarpenter)
(Reporter)

Comment 2

5 years ago
Btw. there are two bugs about a fix in settings: bug 800325 and bug 799030. Looks like it in there but it's not used in the start-up window.
We shouldn't be locking the device access if the SIM is locked in anyway. You should be able to bypass the start-up SIM lock dialog if your SIM is locked (with PIN or PUK).

I am not sure we should offer PUK unlock dialog during start-up. This sounds like a edge case to me. In any case, if the above behavior is implemented correctly, the user with a PUK-locked phone will still be able unlock the SIM in Settings app (like what Daniel said in comment 1).

Can QA verify if the start-up SIM dialog can by bypassed or not (with a PIN locked SIM AND a PUK locked SIM)? It *should*.
Keywords: qawanted
c.c. ochameau, who is working on sim PIN dialog.
I cannot reproduce this and bug 816150.
(Reporter)

Comment 5

5 years ago
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #3)
> Can QA verify if the start-up SIM dialog can by bypassed or not (with a PIN
> locked SIM AND a PUK locked SIM)? It *should*.

Please see bug 816150 for that issue.

> I am not sure we should offer PUK unlock dialog during start-up. This sounds
> like a edge case to me. In any case, if the above behavior is implemented

I haven't had a phone yet which didn't offer that. It's an edge case, but why can't we use the card from settings to do that?
Keywords: unagi
blocking-basecamp: ? → +
Priority: -- → P1
Assignee: nobody → ehung
Since ochameau is working on SIM PIN dialog, re-assign to him first. 

ochameau, if you don't have time to take this, feel free to assign me back. Thanks.
Assignee: ehung → poirot.alex
Hi, 

Tested again with today's build (gaia 23ce635 / gecko 0b1ed65). Now it is possible to introduce PUK after three incorrect PIN attempts. 

However, the interface is not very clear, as there are three boxes where you should introduce PUK and PIN (this twice), but there are no tags explaining this. I think it's a bit confusing for the user. 

Anyway, now it's possible to unlock SIM with the own device.
(In reply to David Palomino [:dpv] from comment #7)
> Hi, 
> 
> Tested again with today's build (gaia 23ce635 / gecko 0b1ed65). Now it is
> possible to introduce PUK after three incorrect PIN attempts. 
> 
> However, the interface is not very clear, as there are three boxes where you
> should introduce PUK and PIN (this twice), but there are no tags explaining
> this. I think it's a bit confusing for the user. 

I have already created a bug about this for :ochameau :) 
https://bugzilla.mozilla.org/show_bug.cgi?id=815988

So, let's close this bug now and you can reopen it if you once again encounter the same problem(whole PUK dialog diseappears.)

> 
> Anyway, now it's possible to unlock SIM with the own device.

That's great.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
The proper status here should be "fixed". Ideally, the commit link should be put in a comment.
Resolution: WORKSFORME → FIXED
(Reporter)

Comment 10

5 years ago
I have tested yesterdays build 2012-12-04 and it is not fixed for me. I will wait for todays build and test again.
(Reporter)

Comment 11

5 years ago
This is not solved for me with todays build. Probably you tested the wrong path given the not correctly set summary and component?
Status: RESOLVED → REOPENED
Component: Gaia::System → Gaia::First Time Experience
Flags: needinfo?(jcarpenter)
Flags: needinfo?(hello)
Resolution: FIXED → ---
Summary: After entering wrong PIN code 3 times on start-up there is no way to enter the PUK code (device lockup) → [FTE] After entering wrong PIN code 3 times on start-up there is no way to enter the PUK code (device lockup)
(Reporter)

Comment 12

5 years ago
Also we should read-out the SIM how many failures already have happened and if there were already >2 we have to display the PUK field immediately and not after 3 additional tries.
Status: REOPENED → NEW
Disregard my comment 3 if you are talking about FTE ... FTE SIM PIN step does block device access, although I have no idea why FTE is designed this way.
(Reporter)

Updated

5 years ago
See Also: → bug 816150
Status: NEW → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 816150
(Assignee)

Comment 15

5 years ago
I disagree on marking this as duplicated of bug 816150. Obviously, they are related, as solving the other one will be a way of solving this one also (just ignore the PIN request), but this bug shows a different malfunction, which is the lack of a PUK input screen.

Maybe we should modify the other bug to include also this one (PIN + PUK), but right now I don't think they can be related as duplicates.

Comment 16

5 years ago
(In reply to Fernando Campo (:fcampo) from comment #15)
> I disagree on marking this as duplicated of bug 816150. Obviously, they are
> related, as solving the other one will be a way of solving this one also
> (just ignore the PIN request), but this bug shows a different malfunction,
> which is the lack of a PUK input screen.
> 
> Maybe we should modify the other bug to include also this one (PIN + PUK),
> but right now I don't think they can be related as duplicates.

I agree. this is not a duplicate of 816150. can we please remove the duplication.
Ok, so I don't know what to do with FTE.
Feel free to pick it up.
Assignee: poirot.alex → nobody
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee: nobody → alive
Currently the FTU has its own SIM PIN screen as the first step(If the card is locked already).
It's not reasonable because the error message has no chance to be translated before you change the language(it's the next step..you cannot go the next step before you lock the card. This is another issue though).

BTW the error message is hardcoded....bad.
document.getElementById('pin_error').innerHTML = 'Error ' + retry;

ping @lco for UX input here because you are the design owner of SIM PIN.

Another question is what could we do here if the PUK is still failed? Block the user to go on in FTU or tell the user to pull out the card?
Flags: needinfo?(lco)
Assignee: alive → nobody
So we have three blocking bugs about PIN in FTU(820711, 816150).
I strongly feel that we have to revisit the design in this part.

First of all, why not use the system side SIM PIN dialog?
Second, if it's for multi-lingual sake, put the step at first step in FTU doesn't help.
Third, SIM lock should be able to be dismissed. If the user determines to dismiss SIM lock, disable data connection step and import contact from SIM card step.

needinfo to Ayman and deassign myself.
Flags: needinfo?(lco) → needinfo?(aymanmaat)
Assignee: nobody → fbsc
(Assignee)

Updated

5 years ago
Assignee: fbsc → fernando.campo

Updated

5 years ago
Assignee: fernando.campo → fbsc
Target Milestone: --- → B2G C3 (12dec-1jan)
(Assignee)

Updated

5 years ago
Assignee: fbsc → fernando.campo

Comment 20

5 years ago
(In reply to Alive Kuo [:alive] from comment #19)
> So we have three blocking bugs about PIN in FTU(820711, 816150).
> I strongly feel that we have to revisit the design in this part.
> 
> First of all, why not use the system side SIM PIN dialog?

Functionality can be the same as the system (settings) dialog, but visuals should match the FTE visuals.

> Second, if it's for multi-lingual sake, put the step at first step in FTU
> doesn't help.

Ayman can comment more because he knows the FTE better than I do, but the simple fix would be to place the sim pin screen after the Language screen, if it's possible.

> Third, SIM lock should be able to be dismissed. If the user determines to
> dismiss SIM lock, disable data connection step and import contact from SIM
> card step.

This is discussed in Bug 8168150, so let's direct all comments about it there.

> 
> needinfo to Ayman and deassign myself.

Comment 21

5 years ago
(In reply to Larissa Co from comment #20)
> (In reply to Alive Kuo [:alive] from comment #19)

> > Second, if it's for multi-lingual sake, put the step at first step in FTU
> > doesn't help.
> 
> Ayman can comment more because he knows the FTE better than I do, but the
> simple fix would be to place the sim pin screen after the Language screen,
> if it's possible.

We cannot place the language screen before the SIM pin screen. if you remember back to v6 of the FTU wireframe pack i specified the language selection before SIM pin because it would make sense for the language of the SIM pin screen to be in the end users desired language. However this architecture got vetoed (I cannot specifically remember why, but it think it was on technical grounds) and this is why SIM pin sits before language selection.
Flags: needinfo?(aymanmaat)
(Assignee)

Comment 22

5 years ago
As it appears after revising notes from months ago, the technical blockage for putting the pin screen after languages screen was based on the possible use of the mcc data to establish a default language. 

As we are not currently using that information (en-US is the hardcoded default language) and I don't see that as important as having the whole FTU in the same language, I would recommend to move the PIN screen after language selection.

Anyway, this bug is related to the PUK code after all attempts of PIN failed, so here's the patch I'm proposing (and working on right now):
- Sync functionality with Settings PIN screen, including number of attempts left (bug 820711), and PUK request if previous failed
- Move the SIM screen after language selection, so we can localize the messages

If you feel like it should be split into separate bugs, ping me
Also, if you have any other comments about the proposal, feel free to comment

Comment 23

5 years ago
(In reply to Fernando Campo (:fcampo) from comment #22)
> As it appears after revising notes from months ago, the technical blockage
> for putting the pin screen after languages screen was based on the possible
> use of the mcc data to establish a default language. 
> 
> As we are not currently using that information (en-US is the hardcoded
> default language) and I don't see that as important as having the whole FTU
> in the same language, I would recommend to move the PIN screen after
> language selection.

if we can return the language selection screen to sit before the SIM PIN screen and therefore have the *whole* FTU procedure in the language the end user desires that would be great. From a UX PoV I am fully supportive of that.
Can we get a current status on this bug? It's been idle for 10 days.
(Assignee)

Comment 25

5 years ago
sorry about that. wasn't idle, but needed to solve other pin-related bugs first. I'm finishing a patch right now, will be uploaded later today or monday (meaning, probably over the weekend ;))

Updated

5 years ago
Target Milestone: B2G C3 (12dec-1jan) → B2G C4 (2jan on)
(Assignee)

Comment 26

5 years ago
Created attachment 698656 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/7322

Kinda big PR, but we have a whole new screen.
Attachment #698656 - Flags: review?(stas)
Attachment #698656 - Flags: review?(fbsc)
Removing qawanted - please let us know if additional QA is needed. Thanks.
Keywords: qawanted

Comment 28

5 years ago
Comment on attachment 698656 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/7322

Grabbing  this review from stas.

PUK is "unblocking", not "unlocking".

Please don't change the keys of strings without changing the strings, pinAttemptMsg vs unlockAttemptMsg. this is is causing work for our l10n teams, and we don't have time for that.

I noticed that I myself had problems remembering that I got a PUK with my SIM. More of a UX concern, but it'd be nice if that full 'Personal Unblocking Key' was written out when the PUK is asked for. I don't know how the screens go together here.
Attachment #698656 - Flags: review?(stas) → review-
(Assignee)

Comment 29

5 years ago
I found every possible combination for the name: Personal Unblocking Key, Personal Unlock Code, Personal Unlocking Key, PIN Unlock Key, PIN Unblock Key, etc, and no idea which one is the official. If you please provide me with some info about the official way to call it I'll be glad to change it.

About changing keys, now we use the same strings for PIN and PUK attempts, so changint it for unlock was a logic step for me. But if it's that much work, I can go back to pinAttemptMsg and duplicate all for pukAttemptMsg.
(Reporter)

Comment 30

5 years ago
I would take a spec as reference:
http://www.ttfn.net/techno/smartcards/gsm11-11.pdf

PUK/PUK2

PIN Unblocking Key / PIN2 Unblocking Key (obsolete terms for UNBLOCK CHV1 and UNBLOCK CHV2, respectively)
(Assignee)

Comment 31

5 years ago
Thanks! So my understanding is that we should use unblock for PIN/PUK codes, and unlock for networks.
Changing it on code, will ping you back when ready
(Assignee)

Comment 32

5 years ago
Comment on attachment 698656 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/7322

I finally didn't change 'unlock' for 'unblock' for consistency reasons, as settings keep the first one.

If we finally want to go for 'unblock', we should change it on both sides, unsure on who should participate on the discussion, if app drivers, ux, or both.
Attachment #698656 - Flags: review- → review?(l10n)

Updated

5 years ago
Attachment #698656 - Flags: review?(l10n) → review+
Refer to this attachment to adjust screens design.
Created attachment 699174 [details]
Folder with the correctvisual design.
Created attachment 699196 [details]
Shows the visual design for this steps
Attachment #699174 - Attachment is obsolete: true
(Assignee)

Comment 36

5 years ago
Comment on attachment 698656 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/7322

Adding kaze for review only the latest changes on strings, that modifies settings
Attachment #698656 - Flags: review?(kaze)
Comment on attachment 698656 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/7322

r=me for the l10n part in FTU and Settings
Attachment #698656 - Flags: review?(kaze) → review+
Keywords: late-l10n
Attachment #698656 - Flags: review?(fbsc) → review+
(Assignee)

Comment 38

5 years ago
Merged https://github.com/mozilla-b2g/gaia/commit/2a3b7e85e8d115b004224c91323abe8da62d45fb
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
(Reporter)

Comment 39

5 years ago
Looks good now.

Has someone tested what's happening when you have entered the wrong PUK code multiple times and it gets locked too?
Status: RESOLVED → VERIFIED
(Assignee)

Comment 40

5 years ago
Not tested (at least myself) as I didn't see any specs for treating such condition, hence is not treated in the code. If you know about those specs, I'll be glad if pointed to the doc.
(Reporter)

Comment 41

5 years ago
(In reply to Fernando Campo (:fcampo) from comment #40)
> Not tested (at least myself) as I didn't see any specs for treating such
> condition, hence is not treated in the code. If you know about those specs,
> I'll be glad if pointed to the doc.

The SIM card will be invalid after 10 wrong tries. We show the remaining tries but not the final message yet. I have logged bug 833029.
You need to log in before you can comment on or make changes to this bug.