1035739 - Nightly doesn't ask for PIN to unlock SIM (so it is not unlocked)

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Matěj Cepl]

Attachment: output of adb logcat

With FxOS with Nightly from http://downloads.geeksphone.com/peak/master/nightly-images-peak-master-2014-07-08.Gecko-c0de5b2.Gaia-eca491b.zip when I restart the machine get from the initial Lockscreen straight to the Homescreen without being asked for the PIN for SIM, so it is not unlocked. Sometimes using Dialer makes the PIN dialog to come up, sometimes I get just an error message that I need a working phone connection to use Dialer. Then usually running the First Time Run Wizard helps.

Comment 1

[:gerard-majax]

I do reproduce this on several devices: Peak, Desire Z.

Comment 2

[Julian Schweinsberg]

I do reproduce this on an Open C using the master branch

Comment 3

[:gerard-majax]

It's okay on my Flame with a build from yesterday (gaia at ea0970f0).

Comment 4

[Julian Schweinsberg]

I have this issue since I'm running master branch (since 2 weeks or so), so I don't know If this is the same issue.
But since commit 2823bf7e1a4eeb63c7b794bbaf5b1c4850565b4d the statusbar is shown opaque after unlocking, so the Event 'simpinshow' seems to get dispatched.

Comment 5

[:gerard-majax]

And it's okay on my Flame, but only the SIM in the second slot has a PIN.

Comment 6

[Jason Smith [:jsmith]]

QA Wanted for branch checks.

Comment 7

[:gerard-majax]

No problem with current master on my Nexus S nor on Flame. Do you still experience this?

Comment 8

[:gerard-majax]

Strange, I still see this on my Desire Z.

Comment 9

[Julian Schweinsberg]

The issue persists on my Open C.

Comment 10

[Duane Dixon [:ddixon]]

Hey Jason, I'm trying to understand if what I'm seeing here is by design behaviour or not.  

I've looked at builds on Flame and Buri.  

I've been using the following STR: 

STR: 
1. Lock SIM using a pin number. 
2. Restart phone and open Dialer, Messages, and Contacts

Actual Results: Unlock SIM screen appears when Dialer, Messages, and Contact Apps are opened.

User has the option to "Skip" or enter the SIM Pin when screen is prompted.  However, if user closes the apps without entering the SIM Pin, and opens them for a second time, the SIM pin screen does not activate.  Is this behaviour by design? Thanks!

Comment 11

[:gerard-majax]

(In reply to Duane Dixon [:ddixon] from comment #10)
> Hey Jason, I'm trying to understand if what I'm seeing here is by design
> behaviour or not.  
> 
> I've looked at builds on Flame and Buri.  
> 
> I've been using the following STR: 
> 
> STR: 
> 1. Lock SIM using a pin number. 
> 2. Restart phone and open Dialer, Messages, and Contacts
> 
> Actual Results: Unlock SIM screen appears when Dialer, Messages, and Contact
> Apps are opened.
> 
> User has the option to "Skip" or enter the SIM Pin when screen is prompted. 
> However, if user closes the apps without entering the SIM Pin, and opens
> them for a second time, the SIM pin screen does not activate.  Is this
> behaviour by design? Thanks!

What you describe is an expected behavior but it's not the one this bug is about.
If you have a SIM PIN configured, you should not have to perform step 2 to get asked to unlock the card. You can skip from this point, and then we expect the behavior that you described.

I noticed that the issue comes again from time to time on my Desire Z. I fear we have some kind of race condition there.

Comment 12

[Jason Smith [:jsmith]]

I think comment 11 addresses your comment.

Comment 13

[Matěj Cepl]

But is fresh, alive, and kicking with Peak and the last Nightly from Geekphone's image.

Comment 14

[Duane Dixon [:ddixon]]

Pre-requisites: Apply SIM Pin to your SIM card. 

STR: 
1. Restart phone. 
2. Unlock the display. 

Actual Results: Unlock SIM screen does not appear when user unlocks the display

Expected Results: Unlock SIM screen appears when user unlocks display after powering up or
 restarting device. 


Issue DOES reproduce in Flame 2.1 and Open_C 2.1

Flame 2.1 Repro? YES 

Environmental Variables:
Device: Flame Master
Build ID: 20140710071153
Gaia: 09642e74e250fbc62db860c808ef188628fca55d
Gecko: f93c0ef45597
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
--------------------------------------------------------------------------------------------
Open_C 2.1 Repro? YES

Environmental Variables:
Device: Open_C Master
Build ID: 20140710071153
Gaia: 09642e74e250fbc62db860c808ef188628fca55d
Gecko: f93c0ef45597
Version: 33.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
--------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------
Issue DOES NOT reproduce in Flame 2.0, 1.4, Buri 2.1, Open_C 2.0

Flame 2.0 Repro? NO

Environmental Variables:
Device: Flame 2.0
Build ID: 20140710065452
Gaia: 35a9b715e7348ec738ff6c8a59f50190390a06f2
Gecko: 9297a56e155e
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
--------------------------------------------------------------------------------------------
Flame 1.4 Repro? NO 

Environmental Variables:
Device: Flame 1.4
Build ID: 20140710073052
Gaia: e273c1f52ed7187e4e0b2d66ed5718f0f20c6eeb
Gecko: 896fa800b72d
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
--------------------------------------------------------------------------------------------
Open_C 2.0 Repro? NO

Environmental Variables:
Device: Open_C 2.0
Build ID: 20140710112849
Gaia: 1bd6e8957ccf310b2f75ba5695b058a2e284df3a
Gecko: 8a86bcf49ef5
Version: 32.0a2 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
--------------------------------------------------------------------------------------------
Buri 2.1 Repro? NO

Environmental Variables:
Device: Buri Master
Build ID: 20140710071153
Gaia: 09642e74e250fbc62db860c808ef188628fca55d
Gecko: f93c0ef45597
Version: 33.0a1 (Master)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Comment 15

[Julian Schweinsberg]

I have seen a difference betweeb restarting b2g and restarting the phone:

When I only restart b2g the dialog shows up when I open Messages, Dialer or Contacts.

But when I restart the phone, via adb or power menu, there is no dialog neither after unlocking the lockscreen nor after opening on of the apps.  As I said in comment #4 , it seems that the Event 'simpinshow' gets dispatched.

Comment 17

[Duane Dixon [:ddixon]]

B2G Inbound Regression Window: 

Last Working

Environmental Variables:
Device: Flame Master
Build ID: 20140704021021
Gaia: 75b1de1c0b0b37f720576d3db5e06eb80e0032b8
Gecko: ad6d3a034431
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First Broken

Environmental Variables:
Device: Flame Master
Build ID: 20140704040721
Gaia: 1ceb4ba53cea0469910b8c9c7668b1833adc75e3
Gecko: 1f5b112f838a
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Last Working Gaia and First Broken Gecko
Issue DOES NOT occur here. 
Gaia: 75b1de1c0b0b37f720576d3db5e06eb80e0032b8
Gecko: 1f5b112f838a

Last Working Gecko and First Broken Gaia
Issue DOES occur here. 
Gaia: 1ceb4ba53cea0469910b8c9c7668b1833adc75e3
Gecko: ad6d3a034431

Gaia Pushlog: 
https://github.com/mozilla-b2g/gaia/compare/75b1de1c0b0b37f720576d3db5e06eb80e0032b8...1ceb4ba53cea0469910b8c9c7668b1833adc75e3

Possible Cause: 

 	Bug 1030415 - Use lockscreen-request-unlock to show homescreen or app

Comment 18

[Joshua Mitchell (Inactive)]

broken by bug 1030415, Alive can you take a look?

Comment 19

[:gerard-majax]

I may have just reproduced it once on my Nexus S, after pushing just the system app.

Comment 20

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

Taken.

Comment 21

[:gerard-majax]

Alive, are you making any progress? This is now 100% reproducing on my Flame.

Comment 22

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

I am not actively on it, feel free to steal it if you are available. Thanks.

Comment 23

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

Could you steal and investigate? thanks.

Comment 24

[(Inactive after June) George Duan [:gduan] [:喬智]]

It looks like, when we unlock the lockscreen and retry to showIfLocked, the System.locked should return false.

Comment 25

[(Inactive after June) George Duan [:gduan] [:喬智]]

Attachment: PR to master

Hi Alive,
the root cause is, sim_lock.js and lockscreen_window_manager are both listening lockscreen-request-unlock event. When sim_lock receive it , it will trigger showIfLocked method and check System.locked's value. However, the value is still true since lockscreen_window_manager has not called closeApp to change the value of states.active. It's a callback function embedded in activeApp.ready.

Before your patch, the activeApp is null since showwindow has not published yet, so LockscreenWindowManager closeApp immediately. 


could you help to review my solution?

Comment 26

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

Comment on attachment 8458704 [details] [review]
PR to master

I think we still want to wait homescreen ready,
so my proposal would be:
in lockscreen-request-unlock handler of sim_lock, listen to lockscreenclosed and remove the closed listener after the event is caught and call showIfLocked().

Thanks for investigation.

Comment 27

[(Inactive after June) George Duan [:gduan] [:喬智]]

Then, we should parse the detail which contains "record" information into lockscreen-appclosed event. Because we don't want to open the dialog while launching camera app.

Comment 28

[(Inactive after June) George Duan [:gduan] [:喬智]]

> 
> I think we still want to wait homescreen ready,
> so my proposal would be:
> in lockscreen-request-unlock handler of sim_lock, listen to lockscreenclosed
Sorry for my misunderstanding, it should work if we put lockscreen-appclosed into lockscreen-request-unlock handler.
> and remove the closed listener after the event is caught and call
> showIfLocked().
> 
> Thanks for investigation.

Comment 29

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment on attachment 8458704 [details] [review]
PR to master

Hi Alive,
I modified my patch by your suggestion. Could you kindly review it again?
Thanks.

Comment 30

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

Comment on attachment 8458704 [details] [review]
PR to master

r+ only if you fix the removeEventListener issue.

Comment 31

[(Inactive after June) George Duan [:gduan] [:喬智]]

Thanks, 
merge to master
https://github.com/mozilla-b2g/gaia/commit/15a831db021ec8b156619c946b2f4ba7e96adbc3

Comment 32

[Julian Schweinsberg]

The SIM PIN dialog is not shown after rebooting the phone.  Gaia is up to date (commit 479199c9).
STR:
1. Reboot the phone via Power menu.
2. Unlock the lockscreen.

The dialog should be shown, but it isn't.  When b2g is restarted via adb shell the SIM PIN dialog is shown after unlocking the lockscreen.

So it seems that there is some sort of state which get cleared through reboot but not through restarting of b2g.

Comment 33

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

Triage: regression.

Comment 34

[Yeojin Chung [:YeojinC]]

This issue is verified fixed on Flame 2.1:

Flame 2.1 

Device: Flame 2.1 KK (319mb) (Full Flash)
BuildID: 20141012001201
Gaia: d18e130216cd3960cd327179364d9f71e42debda
Gecko: 610ee0e6a776
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

"Enter SIM PIN" screen appears properly after restarting the device.