975240 - [DSDS][FTE] SIM 1 or SIM 2 PIN unlock page will still show first ahead of language selection.

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::First Time Experience, defect)

Description

[Enpei]

Attachment: VIDEO0036.mp4

No matter 1 or 2 SIM has PIN enabled, the first page of FTE is Enter SIM 1 or 2(one of it) code page, not language selection. And even skip the first Enter PIN code page, user will be asked again after language selection page.

Based on UX 1.3 spec, language selection should be the first page. 

* Build Number  
Gaia      3df4258b121fb66b4853edb05e68c8c21b18d9d5
Gecko     b2198bb9ae35281102b40a69df8f3fb6069ff4f9
BuildID   20140221074627
Version   28.0

* Reproduce Steps
1. Enable both SIM cards PIN.
2. Flash latest 1.3 or 1.4 fugu build.
3. Check first page.

* Expected Result
The first page is language selection.

* Actual Result
The first page is either Enter SIM 1 or SIM 2 PIN code page. After skip it, you can get SIM 1(or SIM 2) PIN code entry page again after language selection.

* Occurrence rate
100%

Comment 1

[Enpei]

Attachment: time stamp: capture after reboot device

Comment 2

[Enpei]

Buri has no such problem. 
Gaia      a43904d9646109b48836d62f7aa51e499fbf4b2e
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/32fd5d798477
BuildID   20140220004003
Version   28.0

Comment 3

[Eric Chang [:ericcc] [:echang]]

Attachment: P3051229.JPG

Comment 5

[Enpei]

Buri v1.4 still has no such problem.
Gaia      4bb8b32d8f1a3a64bfac8f2da7878dc63e613ca5
Gecko     https://hg.mozilla.org/mozilla-central/rev/c1c3aa2b09d8
BuildID   20140305160201
Version   30.0a1

Comment 6

[Enpei]

Nominate this due to it's a obvious UI duplicate which can be discovered right after first power on device.

Comment 7

[Preeti Raghunath(:Preeti)]

UX

Please weigh in if absolutely needed in 1.4

Comment 8

[Stephany Wilkes]

Since this is DSDS and this is a main focus of 1.4, my inclination is to say yes, but I'm flagging Sandip and Carrie to check me on this.

Comment 9

[Carrie Wang [New account: [e-mail]]]

Yes, this is a bug. Users can tell it as well. :(
Thanks!

Comment 10

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

Let me handle this one.

Comment 11

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

Attachment: patch on master

Comment 12

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

Comment on attachment 8389605 [details] [review]
patch on master

Hi Alive,

simpinlock will show up earlier than ftu got launched. Even though we check isFtuRunning in simpinlock, it is still too late to avoid showing the simpinlock because it is there already !

I think we can catch the ftuopen event to hide the dialog. If there is no such event coming up, it means that users had passed ftu already and we can show the simpinlock based on the current cardState. 

Any feedback is welcome ! Thanks Alive :)

Comment 13

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8389605 [details] [review]
patch on master

Sad workaround, I hope we could do something in system 2 stage 2 to fix this.

Comment 14

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

(In reply to EJ Chen [:eragonj][:小龍哥] from comment #12)
> Comment on attachment 8389605 [details] [review]
> patch on master
> 
> Hi Alive,
> 
> simpinlock will show up earlier than ftu got launched. Even though we check
> isFtuRunning in simpinlock, it is still too late to avoid showing the
> simpinlock because it is there already !
> 
> I think we can catch the ftuopen event to hide the dialog. If there is no
> such event coming up, it means that users had passed ftu already and we can
> show the simpinlock based on the current cardState. 


EJ, do we have any idea why this is only happening on certain devices? Is it just that simpinlock is triggered too fast on Fugu?

Also, is there a way the SIM Pin Unlock screen can check the same thing that system does when deciding whether or not to display ftu, like 'ftu.enabled' storage item [1]? In other words, could we preemptively not display SIM pin unlock screen when FTU is about to pop up?

https://github.com/mozilla-b2g/gaia/blob/3be833ec0126ff3ab3faee463033cee99bb1732e/apps/system/js/ftu_launcher.js#L136

Comment 15

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

(In reply to Michael Henretty [:mhenretty] from comment #14)
> EJ, do we have any idea why this is only happening on certain devices? Is it
> just that simpinlock is triggered too fast on Fugu?

I only have Fugu & Inari to test with and I can all reproduce this problem on these devices. Not sure this would happen on specific devices or not. 

> Also, is there a way the SIM Pin Unlock screen can check the same thing that
> system does when deciding whether or not to display ftu, like 'ftu.enabled'
> storage item [1]? In other words, could we preemptively not display SIM pin
> unlock screen when FTU is about to pop up?

There are many ways to detect this (for me, I use `ftuopen`, and your proposal is another way for sure !), and the most used patterns in System app is `event propagation` and I think that's the better way to communicate between different scripts there.

> https://github.com/mozilla-b2g/gaia/blob/
> 3be833ec0126ff3ab3faee463033cee99bb1732e/apps/system/js/ftu_launcher.js#L136

Comment 16

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

(In reply to EJ Chen [:eragonj][:小龍哥] from comment #15)
> (In reply to Michael Henretty [:mhenretty] from comment #14)
> > EJ, do we have any idea why this is only happening on certain devices? Is it
> > just that simpinlock is triggered too fast on Fugu?
> 
> I only have Fugu & Inari to test with and I can all reproduce this problem
> on these devices. Not sure this would happen on specific devices or not. 

Comment 2 says it doesn't happen on Buri. Very strange, but I guess it's good that it doesn't happen on the production device.

> There are many ways to detect this (for me, I use `ftuopen`, and your
> proposal is another way for sure !), and the most used patterns in System
> app is `event propagation` and I think that's the better way to communicate
> between different scripts there.

The reason I suggested making an explicit check rather than listening for the 'ftuopen' event, is that with waiting for the 'ftuopen' we might still see the sim pin screen pop up for a moment and then close. If you make an explicit check, you can avoid showing this screen in the first place. Perhaps I'm wrong, and with listening for 'ftuopen' the user will never actually see the SIM PIN screen pop up for a moment? In any case, I'll leave it up to you and Alive to figure it out, just thought I'd suggest it :)

Comment 17

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

I just stole one buri and i can reproduce this problem on Buri but .. in a weird situation. Each time when I flash from QA's tool (auto_flash_from_pvt.sh) with master & 1.3 build, I can't reproduce this problem. But when I try to flash with makefile to the same Gaia version, this problem would occur no matter it is master or 1.3. 

Not sure what's the difference between flashing from QA's tool and from makefile ... Hmmmm interseting.

Comment 18

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

(In reply to EJ Chen [:eragonj][:小龍哥] from comment #17)
> I just stole one buri and i can reproduce this problem on Buri but .. in a
> weird situation. Each time when I flash from QA's tool
> (auto_flash_from_pvt.sh) with master & 1.3 build, I can't reproduce this
> problem. But when I try to flash with makefile to the same Gaia version,
> this problem would occur no matter it is master or 1.3. 
> 
> Not sure what's the difference between flashing from QA's tool and from
> makefile ... Hmmmm interseting.

That is weird! How are you flashing from the Makefile, `make production`, 'make reset-gaia` or `make install-gaia`?

Comment 19

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

(In reply to Michael Henretty [:mhenretty] from comment #18)
> That is weird! How are you flashing from the Makefile, `make production`,
> 'make reset-gaia` or `make install-gaia`?

I use `make reset-gaia` xD

Comment 20

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

To be consistent with QA's testing environment, I think it would be better to use "QA tool" to flash the gaia & gecko to check the problem. 

In order to find out the problem, I flash with QA tool and `make install-gaia APP=system` to make sure I only override the few files with console. Here comes some logs (I took off some unnecessary logs by the way) :

Inari : 

E/GeckoConsole(  579): Content JS LOG at app://system.gaiamobile.org/js/ftu_launcher.js:156 in getItem/req.onsuccess: ftu is going to launch
E/GeckoConsole(  579): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:153 in sl_showIfLocked: each run
E/GeckoConsole(  579): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:153 in sl_showIfLocked: each run
E/GeckoConsole(  579): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:55 in sl_handleEvent: received event >  will-unlock
E/GeckoConsole(  579): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:153 in sl_showIfLocked: each run
E/GeckoConsole(  579): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:158 in sl_showIfLocked: pass lockscreen test
E/GeckoConsole(  579): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:160 in sl_showIfLocked: true
E/GeckoConsole(  579): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:55 in sl_handleEvent: received event >  appopened

Fugu :

E/GeckoConsole( 1119): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:153 in sl_showIfLocked: each run
E/GeckoConsole( 1119): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:55 in sl_handleEvent: received event >  will-unlock
E/GeckoConsole( 1119): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:153 in sl_showIfLocked: each run
E/GeckoConsole( 1119): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:158 in sl_showIfLocked: pass lockscreen test
E/GeckoConsole( 1119): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:160 in sl_showIfLocked: false
E/GeckoConsole( 1119): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:165 in sl_showIfLocked: pass ftu test
E/GeckoConsole( 1119): Content JS LOG at app://system.gaiamobile.org/js/ftu_launcher.js:156 in getItem/req.onsuccess: ftu is going to launch
E/GeckoConsole( 1119): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:55 in sl_handleEvent: received event >  appopened
E/GeckoConsole( 1119): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:153 in sl_showIfLocked: each run
E/GeckoConsole( 1119): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:158 in sl_showIfLocked: pass lockscreen test
E/GeckoConsole( 1119): Content JS LOG at app://system.gaiamobile.org/js/sim_lock.js:160 in sl_showIfLocked: true

We can notice that the launching time of FTU is different and that's why we there are different behaviors between devices.

Comment 21

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

(In reply to EJ Chen [:eragonj][:小龍哥] from comment #20)
> We can notice that the launching time of FTU is different and that's why we
> there are different behaviors between devices.

Typo : We can notice that the launching time of FTU is different and that's why there are different behaviors between devices.

We may have to make sure the loading sequence in system 2 !

Comment 22

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

Thanks all, merged in Gaia/master : a5aa02d4c4194abd85af2dbf84c0b18e3cb84d59

Comment 23

[Enpei]

Verified on Fugu
Gaia      1d1667e316f9ba1ae7a3d11b600a0e1878472433
Gecko     5d1e3faff6b221e411a5777edd60ab70672407f2
BuildID   20140320053057
Version   31.0a1