Closed Bug 963682 Opened 7 years ago Closed 7 years ago

[B2G] The user is given a message to input the SIM PIN just after entering the SIM PIN.

Categories

(Firefox OS Graveyard :: Gaia::Cost Control, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

VERIFIED FIXED
1.4 S1 (14feb)
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed

People

(Reporter: jharvey, Assigned: salva)

References

Details

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

Attachments

(2 files)

Description:
An unnecessary message appears telling the user to enter their SIM PIN after just entering the SIM PIN when airplane mode is disabled.

Repro Steps:
1) Updated Buri 1.3 to Build ID: 20140124004002
2) Use a phone with SIM PIN enabled.
3) Slide down the quick menu and enable airplane mode.
4) Disable airplane mode.
5) Slide up and down to refresh the quick menu.
6) Select "Unlock SIM card to enable Usage."
7) Input the SIM PIN and press OK. 

Actual:
The message "Locked SIM card. Unlock your SIM to enable Usage." after the user just entered the SIM PIM.

Expected:
No message appears after user inputs the SIM PIN.

Environmental Variables
Device: Buri 1.3 Mozilla
Build ID: 20140124004002
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/a73b697b50b3
Gaia: e5137ed5589d7f3bf0260b8920f874cd0f462f69
Platform Version: 28.0a2
Firmware Version: v1.2-device.cfg

Repro Rate: 100%
See attached: Video.mp4
This issue does not reproduce on Buri 1.2

Environmental Variables
Device: Buri 1.2 Mozilla
Build ID: 20140123004001
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/4494940fb3ea
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Platform Version: 26.0
Firmware Version: V1.2-device.cfg
Attached video video.mp4
Sounds like basic bustage here then - we're indicating a SIM is locked when it actually isn't locked.
blocking-b2g: --- → 1.3?
Component: Gaia → Gaia::System
QA Contact: pbylenga
The regression window is 10-02-2013 to 10-03-2013.  

First nightly build issue reproduced in:
v1.3 Environmental Variables:
Device: buri v1.3 MOZ
BuildID: 20131003040204
Gaia: dc68f530ca7d1b182deef0a3787cfdd8f0778612
Gecko: 0e26e6f12ad9
Version: 27.0a1
Firmware Version: v1.2-device.cfg

The last nightly build issue did not reproduce in:
v1.3 Environmental Variables:
Device: buri v1.3 MOZ
BuildID: 20131002040206
Gaia: 73a64d360f0ed135fcca205c6292e9219e085413
Gecko: e3c84e9f2490
Version: 27.0a1
Firmware Version: v1.2-device.cfg
blocking-b2g: 1.3? → 1.3+
Whiteboard: burirun1.3-2 → burirun1.3-2 [systemsfe]
Tim, your team is mostly doing changes to sim lock and window management. Can you take a look here?
Flags: needinfo?(timdream)
Whiteboard: burirun1.3-2 [systemsfe] → burirun1.3-2,
After manually reproduce the STR, I found the following:

* The step 7 dialog is in System app.
* Step 8 alert() is implemented in Usage.

This is not a System app bug.
Component: Gaia::System → Gaia::Cost Control
Flags: needinfo?(timdream)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #6)
> After manually reproduce the STR, I found the following:
> 
> * The step 7 dialog is in System app.
> * Step 8 alert() is implemented in Usage.
> 
> This is not a System app bug.

This same issue has been reported in Bug 962120

The Usage behaviour when the SIM is locked and the user launchs the application, is the following:
  1. Costcontrol application display the following message "Locked SIM card. Unlock your SIM to enable   Usage".
  2. When the user presses the button "OK" the application is closed.

Right now, the system process launchs automatically a screen to enter pin code overlapping the screen message ("Locked SIM card. Unlock your SIM to enable Usage") 

So if the user unlocks the SIM and the "enter pin screen" is closed the user reads the message: "Locked SIM card. Unlock your SIM to enable Usage" which is rare or confused for the user, because the sim is already unlocked.

Due to time constraints Ayman has recommended we simpl remove the dialogue that states "Locked SIM card. Unlock your SIM to enable Usage." which would leave just the enter SIM PIN dialogue for the user to interact with before accessing the app.
Duplicate of this bug: 962120
Assignee: nobody → salva
Depends on: 948824
This is a WIP. It lacks from tests, don't merge yet.
ni to Ayman to confirm the new flow implemented is fine from a UX PoV. Thanks!
Flags: needinfo?(aymanmaat)
(In reply to Noemí Freire (:noemi) from comment #11)
> ni to Ayman to confirm the new flow implemented is fine from a UX PoV.
> Thanks!

Fine for this version from my PoV
Flags: needinfo?(aymanmaat)
Blocks: 960500
Attachment #8368115 - Flags: feedback?(francisco.jordano) → feedback?(mri)
Attachment #8368115 - Flags: feedback?(mri) → review?(mri)
Comment on attachment 8368115 [details]
Providing a fake modal dialog to prevent the user to interact with the application unless the SIM is ready.

Everything works fine, great job!

thanks Salva.
Attachment #8368115 - Flags: review?(mri) → review+
master: 397f3aace4a1ba169ad7bda144b33710bc3ce818
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.4 S1 (14feb)
Uplifted 397f3aace4a1ba169ad7bda144b33710bc3ce818 to:
v1.3: bb36b4164d3e51ca04b612e507e1178f80bf240d
The NonReadyScreen stuff causes jslint to fail on 1.3. Can we get a quick patch for this?

https://travis-ci.org/mozilla-b2g/gaia/jobs/18157690
Flags: needinfo?(salva)
nevermind, just fixed it myself since it was easy:
v1.3: https://github.com/mozilla-b2g/gaia/commit/01e556902cf36d1958b98e18f3331d0b99a9be69
Flags: needinfo?(salva)
Tested (02/04/2014)and working:
1.3
Gecko: 2905062
Gaia: bb36b41
Status: RESOLVED → VERIFIED
(In reply to Michael Henretty [:mhenretty] from comment #16)
> The NonReadyScreen stuff causes jslint to fail on 1.3. Can we get a quick
> patch for this?
> 
> https://travis-ci.org/mozilla-b2g/gaia/jobs/18157690

The new linter does not complain about that code style while the former one does.
(In reply to Salvador de la Puente González [:salva] from comment #19)
> The new linter does not complain about that code style while the former one
> does.

Yes this is unfortunate. The new linter (jshint) is more concerned with detecting code problems, while the old linter (gjslint) was very concerned with style. Unfortunately it does not seem we are able to configure jshint to care about 'function()' code style, or to configure gjslint not to care. So as long as 1.3 is around, we will have this problem. Perhaps in the future we can add a style linter to travis (https://github.com/mdevils/node-jscs) but for the time being we will have to deal with these little discrepancies.
You need to log in before you can comment on or make changes to this bug.