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

Status: VERIFIED FIXED

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

Description

[Harvey]

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

Comment 1

[Harvey]

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

Comment 2

[Harvey]

Attachment: video.mp4

Comment 3

[Jason Smith [:jsmith]]

Sounds like basic bustage here then - we're indicating a SIM is locked when it actually isn't locked.

Comment 4

[Peter Bylenga [: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

Comment 5

[Gregor Wagner [:gwagner]]

Tim, your team is mostly doing changes to sim lock and window management. Can you take a look here?

Comment 6

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

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.

Comment 7

[Maria Angeles Oteo (:oteo)]

(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.

Comment 9

[Salvador de la Puente González [:salva]]

Attachment: Providing a fake modal dialog to prevent the user to interact with the application unless the SIM is ready.

Please, see the video for the new flow here:
http://www.youtube.com/watch?v=BqX8fLCUFlQ

Comment 10

[Salvador de la Puente González [:salva]]

This is a WIP. It lacks from tests, don't merge yet.

Comment 11

[Noemí Freire (:noemi)]

ni to Ayman to confirm the new flow implemented is fine from a UX PoV. Thanks!

Comment 12

[ayman maat :maat]

(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

Comment 13

[Marina Rodríguez [:mai]]

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.

Comment 14

[Salvador de la Puente González [:salva]]

master: 397f3aace4a1ba169ad7bda144b33710bc3ce818

Comment 15

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 397f3aace4a1ba169ad7bda144b33710bc3ce818 to:
v1.3: bb36b4164d3e51ca04b612e507e1178f80bf240d

Comment 16

[Michael Henretty [:mikehenrty][:mhenretty]]

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

Comment 17

[Michael Henretty [:mikehenrty][:mhenretty]]

nevermind, just fixed it myself since it was easy:
v1.3: https://github.com/mozilla-b2g/gaia/commit/01e556902cf36d1958b98e18f3331d0b99a9be69

Comment 18

[Loli (:lolimartinezcr)]

Tested (02/04/2014)and working:
1.3
Gecko: 2905062
Gaia: bb36b41

Comment 19

[Salvador de la Puente González [:salva]]

(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.

Comment 20

[Michael Henretty [:mikehenrty][:mhenretty]]

(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.