:gerard-majax Reporter
	Description • 10 years ago

Since several weeks I have noticed a bad race condition that happens everytime I do flash a new build.

STR:
 0. ./repo sync gecko gaia && ./build.sh && ./flash.sh
 1. Device boots

Expected:
 SIM card is detected, PIN code asked

Actual:
 No PIN code is asked, no "No SIM card" message displayed. Settings shows "SIM card not ready". Toggling Airplane mode does not help. Rebooting makes everything fine.

This is reproduced 100% on my Xperia ZR, everytime that Gecko and/or Gaia changes. If I just rebuild and reflash after, it's fine. I suspect that we may have a nasty race condition that is triggered on boot when we perform some updating tasks. I could not get this to reproduce on Flame, JB or KK. But it's 100% on ZR (APQ8064, 2GB)

Hsin-Yi, would you have any idea if this could be a RIL-side issue ?

	:gerard-majax Reporter
	Comment 1 • 10 years ago

Maybe a window/lockscreen issue in fact ...

I just reproduced it again right now, with the very same STRs on my Xperia ZR. However, when I launched the Messages app, I got the SIM PIN dialog.

Could it be something bad in Lockscreen?

	Greg Weng [:snowmantw][:gweng][:λ]
	Comment 2 • 10 years ago

Follow your STR my Flame works well, at least it:

1. SIM PIN dialog pop up after unlocking, if I flash it with LockScreen enabled.
2. SIM PIN dialog directly pop up after rebooting, if I flash it with LockScreen disabled.
3. If flash with FTU, FTU would ask SIM PIN. Skip it, and reboot the device, the SIM PIN dialog would pop up after rebooting

I flash it with QA tool to fetch Gecko/Gaia from PVT, and flash Gaia only to test with LockScreen disabled case. And I think, if your issue only exists when flashing via a specific way, we may encounter some Gecko & Gaia issue but not only a Gaia bug.

If you want I can post the video. But I think it would be better if you can test it with reference device.

My device is:

Gaia-Rev        c2c55870de22d596de4f41612c0b44090f90ebad
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/0b81c10a9074
Build-ID        20141102160202
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  39
FW-Date         Thu Oct 16 18:19:14 CST 2014
Bootloader      L1TC00011880

---

Another issue is from your description, the

    Settings shows "SIM card not ready"

Shows this bug may be totally irrelevant with LockScreen (I don't think LockScreen can manage SIM card as this). However, since I'm just an untitled developer and may not know SIM & System & Settings as others well, I NI Tim to see whether we should change the component.

	:gerard-majax Reporter
	Comment 3 • 10 years ago

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #2)
> Follow your STR my Flame works well, at least it:
> 
> 1. SIM PIN dialog pop up after unlocking, if I flash it with LockScreen
> enabled.
> 2. SIM PIN dialog directly pop up after rebooting, if I flash it with
> LockScreen disabled.
> 3. If flash with FTU, FTU would ask SIM PIN. Skip it, and reboot the device,
> the SIM PIN dialog would pop up after rebooting
> 
> I flash it with QA tool to fetch Gecko/Gaia from PVT, and flash Gaia only to
> test with LockScreen disabled case. And I think, if your issue only exists
> when flashing via a specific way, we may encounter some Gecko & Gaia issue
> but not only a Gaia bug.

It's not about flashing a specific way, but flashing a build that triggers some upgrade on boot.
That happens everytime I reflash a new system partition with a new set of gecko/gaia.

> 
> If you want I can post the video. But I think it would be better if you can
> test it with reference device.

The point is, the issue is not getting trivially exposed on my Flame as it is exposed on the ZR.

[...]

> 
> Another issue is from your description, the
> 
>     Settings shows "SIM card not ready"
> 
> Shows this bug may be totally irrelevant with LockScreen (I don't think
> LockScreen can manage SIM card as this). However, since I'm just an untitled
> developer and may not know SIM & System & Settings as others well, I NI Tim
> to see whether we should change the component.

This part of the report may have been wrong: in all the recent retries where I triggered the bug, there was just "Emergency calls only".

	:gerard-majax Reporter
	Comment 5 • 10 years ago

In bug 1081373 comment 2 it is documented that this is reproduced on a device with software home button. That's the case of my Xperia ZR, so maybe it plays a role.

I'll make sure the next time I reproduce, but as far as I can tell:
 - "Emergency calls only" dsplayed, no "No SIM card" message
 - Starting dialer opens the SIM PIN dialog.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 6 • 10 years ago

Judging by how vulnerable our app start-up code path is, I am not surprised if something other than lock screen break the SIM Pin; even API changes. 

Let's find the regressed bug to actually pin pointing the root cause before finding the right component.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 7 • 10 years ago

Actually in Alex said states "every time Gecko/Gaia changes" in comment 0 and Greg can't reproduce it on Flame in comment 2, so this bug is impossible for QA to reproduce.

We unfortunately had to dig into SIM Pin dialog directly on this one on that machine.

	:gerard-majax Reporter
	Comment 8 • 10 years ago

Reproduced after building/flashing right now. After booting:
 - "Emergency calls only" on the lockscreen
 - no SIM PIN unlock dialog when unlocking the lockscreen
 - SIM is exposed as "locked" in Settings

I get the SIM PIN dialog after either:
 - locking screen while on the Settings app and unlocking
 - launching Dialer

	Greg Weng [:snowmantw][:gweng][:λ]
	Comment 9 • 10 years ago

If your result is still on your device only (my Flame, as you and I commented, can't reproduce this bug), what I can do is to find a device similar to yours so that I can reproduce this bug and maybe QA can try to find the possible regression window. But since this is an indeterminate step that depends on whether we have such devices and whether the bug would occur on them, please understand that I can't give you any guarantees . A better result is we can find a Flame STR so that we can start to debug and investigate it as other bugs.

Beside that, what's your reason to suspect LockScreen is the most possible component breaking the function? And if this is a regression, can you do a Gaia bisect on your device (not Gecko, since bisect Gecko is too painful...)? If you already have such information, we may give a better look rather than monkey patching without the actual broken device, that must be the most inefficient way to debug.

	:gerard-majax Reporter
	Comment 10 • 10 years ago

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #9)
> If your result is still on your device only (my Flame, as you and I
> commented, can't reproduce this bug), what I can do is to find a device
> similar to yours so that I can reproduce this bug and maybe QA can try to
> find the possible regression window. But since this is an indeterminate step
> that depends on whether we have such devices and whether the bug would occur
> on them, please understand that I can't give you any guarantees . A better
> result is we can find a Flame STR so that we can start to debug and
> investigate it as other bugs.

I know. Gregor have something simi

> 
> Beside that, what's your reason to suspect LockScreen is the most possible
> component breaking the function? And if this is a regression, can you do a
> Gaia bisect on your device (not Gecko, since bisect Gecko is too
> painful...)? If you already have such information, we may give a better look
> rather than monkey patching without the actual broken device, that must be
> the most inefficient way to debug.

I don't know. I noticed it, sorry for not logging a timestamp each time I meet Isn't Lockscreen the component that triggers

	:gerard-majax Reporter
	Comment 11 • 10 years ago

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #9)
> If your result is still on your device only (my Flame, as you and I
> commented, can't reproduce this bug), what I can do is to find a device
> similar to yours so that I can reproduce this bug and maybe QA can try to
> find the possible regression window. But since this is an indeterminate step
> that depends on whether we have such devices and whether the bug would occur
> on them, please understand that I can't give you any guarantees . A better
> result is we can find a Flame STR so that we can start to debug and
> investigate it as other bugs.

I know. Sorry for finding 100% reproducible bugs on other devices that then reference one, but my history on this topic mainly shows that issues we have on other devices tends to popup at some point on those we care about. The sooner we fix, the better. Gregor have experienced some simiar issues on his Flame or on other device, I can't remember which one.

Xperia ZR is a APQ8064 (Quad Core) 2GB LTE device. That's close to a Nexus 4, just the modem is not the same.

> 
> Beside that, what's your reason to suspect LockScreen is the most possible
> component breaking the function? And if this is a regression, can you do a
> Gaia bisect on your device (not Gecko, since bisect Gecko is too
> painful...)? If you already have such information, we may give a better look
> rather than monkey patching without the actual broken device, that must be
> the most inefficient way to debug.

I don't know. I noticed it, sorry for not logging a timestamp each time I meet an issue.
Besides, isn't Lockscreen one component that is involved in triggering events that will indeed show the SIM PIN dialog ?

Maybe I should also check whether this may not be another manifestation of the race exposed in bug 976497.

	:gerard-majax Reporter
	Comment 12 • 10 years ago

So I checked with the patch from bug 976497: no change. SIM card is indeed properly detected.
Greg, how can I enable much debug in lockscreen interactions with SIM PIN to try to find something ?

Besides, Gregor *do* reproduce something that looks very close to this bug on Flame.

	:gerard-majax Reporter
	Comment 13 • 10 years ago

Another thing I noticed: if I start Dialer, I may have to press home and switch back again to Dialer to get the SIM PIN dialog displayed.

	Gregor Wagner [:gwagner]
	Comment 14 • 10 years ago

(In reply to Alexandre LISSY :gerard-majax from comment #12)
> So I checked with the patch from bug 976497: no change. SIM card is indeed
> properly detected.
> Greg, how can I enable much debug in lockscreen interactions with SIM PIN to
> try to find something ?
> 
> Besides, Gregor *do* reproduce something that looks very close to this bug
> on Flame.

I see some race-condition on my flame (fresh 2.1 build from today)
I have 2 PIN prodected SIMs in my flame. After a reboot and unlocking the lock-screen I only see 9 out of 10 times the PIN dialog for the 2nd SIM. Once I am on the home-screen and open the dialer app I get asked to enter the PIN for the 1st SIM.

	Gregor Wagner [:gwagner]
	Comment 15 • 10 years ago

Video: https://www.youtube.com/watch?v=DfI8xzSdV7w&feature=youtu.be

	Greg Weng [:snowmantw][:gweng][:λ]
	Comment 16 • 10 years ago

Although I suspect that they're the same bug since because the differences of the symptoms and STRs (1 SIM vs 2 SIMs; totally disappearing vs. incorrect opened dialogs), I think if this is a reproducible bug on Flame and it's actually a regression, as this bug marked, maybe QA can help to find the regression window than I can do some bisect to pin down the possible broken patch, as we handling other regression bugs. However, I don't know if we solve the Gregor's bug, whether Alexandre's would be resolved as well. Or maybe we should fire another bug for Gregor's, and to find the regression and handle it as I said.

For LockScreen debugging you can set console.log or break points at debugger as other code in Gaia. Since you suspect it's caused by racing of control flags, you may take a look at the old lockscreen.js which now unfortunately still take some responsibility to control LockScreen, and the window-related lockscreen_window_manager.js and lockscreen_window.js which now control the window relevant stuffs like when to open the window to show it. I would take a Nexus 4 and try it later as I described, but I think you can take a look on ZR, too.

	:gerard-majax Reporter
	Comment 17 • 10 years ago

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #16)
> Although I suspect that they're the same bug since because the differences
> of the symptoms and STRs (1 SIM vs 2 SIMs; totally disappearing vs.
> incorrect opened dialogs), I think if this is a reproducible bug on Flame
> and it's actually a regression, as this bug marked, maybe QA can help to
> find the regression window than I can do some bisect to pin down the
> possible broken patch, as we handling other regression bugs. However, I
> don't know if we solve the Gregor's bug, whether Alexandre's would be
> resolved as well. Or maybe we should fire another bug for Gregor's, and to
> find the regression and handle it as I said.
> 
> For LockScreen debugging you can set console.log or break points at debugger
> as other code in Gaia. Since you suspect it's caused by racing of control
> flags, you may take a look at the old lockscreen.js which now unfortunately
> still take some responsibility to control LockScreen, and the window-related
> lockscreen_window_manager.js and lockscreen_window.js which now control the
> window relevant stuffs like when to open the window to show it. I would take
> a Nexus 4 and try it later as I described, but I think you can take a look
> on ZR, too.

No, I have no idea *what* could be racing, and you changed a lot of things to the logic around lockscreen. Given the way I reproduce, I cannot play with a debugger, so I need your help with a patch enabling as much as verbose debugging as possible to track this.

	:gerard-majax Reporter
	Comment 18 • 10 years ago

And looking at Gregor's video, given that my ZR only has one SIM card, it's very likely that we are indeed facing the same race. Since we have STRs on Flame, please have a look at this. Let's fix Gregor's issue, there's something obviously broken there, and we will see if it fixes my issue.

	Greg Weng [:snowmantw][:gweng][:λ]
	Comment 19 • 10 years ago

Sorry, I may misunderstand that I originally think you have some guessing about the racing, so I point the possible file to debug with. But in fact, what I have now is as much as yours, this means the thing I can do is to add console.log crazily at the possible points I list and to see if we can catch some real thing.

> Since we have STRs on Flame, please have a look at this. Let's fix Gregor's issue, there's something obviously broken there, and we will see if it fixes my issue.

As my above comment: since this is a regression as you marked, it would be better to either

1. change this bug's title and submit a new description to a Flame bug for Gregor's STR
2. fire another bug for Gregor's STR and keep this bug for ZR only

And then we can follow the standard regression flow to get help from QA to get regression window and I can do some further work based on that, just like other regression bugs.

	:gerard-majax Reporter
	Comment 20 • 10 years ago

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #19)
> Sorry, I may misunderstand that I originally think you have some guessing
> about the racing, so I point the possible file to debug with. But in fact,
> what I have now is as much as yours, this means the thing I can do is to add
> console.log crazily at the possible points I list and to see if we can catch
> some real thing.
> 
> > Since we have STRs on Flame, please have a look at this. Let's fix Gregor's issue, there's something obviously broken there, and we will see if it fixes my issue.

If it can help finding leads on my issue, feel free to attach a patch.

> 
> As my above comment: since this is a regression as you marked, it would be
> better to either
> 
> 1. change this bug's title and submit a new description to a Flame bug for
> Gregor's STR
> 2. fire another bug for Gregor's STR and keep this bug for ZR only
> 
> And then we can follow the standard regression flow to get help from QA to
> get regression window and I can do some further work based on that, just
> like other regression bugs.

I don't see what is preventing us already: we have STRs documented for Flame, and the way it is exposed makes it very likely to be the same issue as the one I have.

If fixing Gregor's issue do not fix mine, then we will file another bug.

	:gerard-majax Reporter
	Comment 21 • 10 years ago

Ok, just tell me where I should switch current logging capabilities ...

	:gerard-majax Reporter
	Comment 22 • 10 years ago

[Blocking Requested - why for this release]: Hitting v2.1 with 2 SIM with PIN, confere comment 14.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 23 • 10 years ago

https://github.com/mozilla-b2g/gaia/blob/master/apps/system/lockscreen/js/lockscreen_state_logger.js#L30-L38

Pass difference value to the logger.

https://github.com/mozilla-b2g/gaia/blob/master/apps/system/lockscreen/js/lockscreen_state_manager.js#L73-L76

You can do it with DevTools or hardcode it.

	Greg Weng [:snowmantw][:gweng][:λ]
	Comment 24 • 10 years ago

I've took a glance at sim_lock to see the condition to pop-up the dialog, the LockScreen related lines are:

https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/sim_lock.js#L116
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/sim_lock.js#L130

(for master, I'll check 2.1 later, since we now still don't know whether 2.2 has this issue, too. Because your bug is (from the comment) on master, while Gregor's is on 2.1)

I follow Gregor's STR, and the code shows that:

1. After LockScreen get closed at L116, the dialog pop-up as the video shows.
2. It's now should be at L87: the dialog want to close itself. And it get closed.
3. When Gregor open the dialer app, it jump to L142 and pass the conditions then goto the L175 to showIfLocked again
4. At the magic L201 it try to iterate the SIMs to see if the dialog can be opened (again, since we has close it once at step 2). And for SIM2 it would directly pass to L221, while L217 block the SIM1 pop-up again.
5. So now we're at L221, and the following code there is no one block us to open the dialog for SIM2. So Gregor saw the second dialog for SIM2.

I don't know whether my tracing is correct or not since most parts of the code was not patched by me (you can blame it), and sorry for this moment I don't know whether the only one patch would cause the issue. But I think the SIM2 poping-up seems a sure thing would happen if the steps I describe here is correct and miss nothing about it.

	:gerard-majax Reporter
	Comment 26 • 10 years ago

Logcat obtained on my ZR after applying changes documented in attachment 8518150 [details].

	:gerard-majax Reporter
	Comment 27 • 10 years ago

And now, logging after:
 - unlock,
 - start settings, wait for it to load
 - lock
 - unlock

Which makes the PIN dialog diplayed

	Greg Weng [:snowmantw][:gweng][:λ]
	Comment 28 • 10 years ago

Sorry, I think what Tim mentioned is not a correct logger for this case, and I don't know why he suggested to log state machine to solve this case. The logger now doesn't fully cover all LockScreen functions (the refactoring which try to achieve this is on going) especially for this case which occur at the unlocking and sim pin dialog. Anyway, I now focus on Gregor's case and as you can see, the possible root cause for his case is in sim_lock.js. I'll try debugging it tomorrow, with the help from someone know the component better than me. I suggest let's wait to see if I can solve the two cases at the same patch, or what happened on ZR is actually another case as we discussed.

	Gregor Wagner [:gwagner]
	Comment 29 • 10 years ago

Assigning to Greg based on comment 28.

	Greg Weng [:snowmantw][:gweng][:λ]
	Comment 30 • 10 years ago

Please understand what I commented is the possible root causes indicates to sim_lock.js, which is a file that I don't have enough knowledge to debug with, and according to Tim's opinion this still need to see whom can handle with it. So I don't feel I'm the proper person to take this bug.

	:gerard-majax Reporter
	Comment 31 • 10 years ago

Taking, to make sure we fix this.

	Gregor Wagner [:gwagner]
	Comment 32 • 10 years ago

I believe we want to support dual sim on 2.1.

	:gerard-majax Reporter
	Comment 33 • 10 years ago

This is now appearing consistently also on my Nexus S ... That was not the case a couple of days ago.

	:gerard-majax Reporter
	Comment 34 • 10 years ago

Yay, and of course, it's not appeararing anywhere else, specifically on my Flame.

	:gerard-majax Reporter
	Comment 35 • 10 years ago

Trick:
 - hack edit-prefs.sh to do |adb reboot| instead of |adb shell start b2g|
 - use edit-prefs.sh, and change:
   - gecko.buildID to 1234
   - gecok.mtone to 1.0

On next reboot, PIN code for SIM 2 is asked, but not for SIM 1.

	:gerard-majax Reporter
	Comment 36 • 10 years ago

This helps to reproduce. Not 100% though, but still a good number.

	:gerard-majax Reporter
	Comment 37 • 10 years ago

I think I have another symptom:
 - unlock device
 - cancel the PIN for SIM 1
 - you don't get the SIM PIN dialog for SIM 2

	:gerard-majax Reporter
	Comment 38 • 10 years ago

Performing several reset-gaia with hard-coded lockscreen disabled:
 - on v2.1, I always get SIM PIN dialog
 - on master, I never get SIM PIN dialog

	Gabriela [:gaby2300]
	Comment 39 • 10 years ago

I cannot reproduce this bug with my Flame using base image v188, FFOS 2.2 and today's OTA update.

	:gerard-majax Reporter
	Comment 40 • 10 years ago

Reproduced again with flashing a new Gecko on Xperia ZR. I had a look at the logcat,

> $ egrep 'SimLock|SimManager' boot-upgrade-nosimpin.log boot-upgrade-after-simpin.log 
> boot-upgrade-nosimpin.log:11-13 16:34:54.415   265   265 E GeckoConsole:     at SimLockSystemDialog.prototype.handleCardState/request.onerror (app://system.gaiamobile.org/js/sim_lock_system_dialog.js:222:6)
> boot-upgrade-nosimpin.log:11-13 16:35:40.780   265   265 I GeckoDump: [system] [SimLockManager][49.307] handling lockscreen-request-unlock
> boot-upgrade-nosimpin.log:11-13 16:35:49.278  1507  1507 W Usage   : Content JS WARN: SimManager is not ready, waiting for initialized custom event 
> boot-upgrade-after-simpin.log:11-13 16:34:55.085   268   268 E GeckoConsole:     at SimLockSystemDialog.prototype.handleCardState/request.onerror (app://system.gaiamobile.org/js/sim_lock_system_dialog.js:222:6)
> boot-upgrade-after-simpin.log:11-13 16:35:22.422   268   268 I GeckoDump: [system] [SimLockManager][30.450] handling lockscreen-request-unlock

So it could be from SimManager ?

	:gerard-majax Reporter
	Comment 41 • 10 years ago

Carefully looking at logs, I *always* see bug 1098220 when I don't have the SIM PIN dialog. Gregor, do you corroborate this?

	Marek Raida
	Comment 42 • 10 years ago

I have this issue in only one SIM and every time...

	:gerard-majax Reporter
	Comment 43 • 10 years ago

Not sure if it's related, but I see this when adding some debug and reproducing on my ZR:

>  2936 11-13 18:50:36.474   269   269 D GeckoConsole: Content JS DEBUG: [DAFUK] SimLockManager: Already displayed.
>  2937 11-13 18:50:36.474   269   269 D GeckoConsole:     at .warn (app://system.gaiamobile.org/js/sim_lock_manager.js:163:6)
>  2938 11-13 18:50:36.474   269   269 D GeckoConsole: Content JS DEBUG: [DAFUK] SimLockManager: stack: .warn@app://system.gaiamobile.org/js/sim_lock_manager.js:164:58
>  2939 11-13 18:50:36.474   269   269 D GeckoConsole: sl_showIfLocked@app://system.gaiamobile.org/js/sim_lock_manager.js:184:9
>  2940 11-13 18:50:36.474   269   269 D GeckoConsole: lockscreenOnClosed@app://system.gaiamobile.org/js/sim_lock_manager.js:124:11
>  2941 11-13 18:50:36.474   269   269 D GeckoConsole: AppWindow.prototype.publish@app://system.gaiamobile.org/gaia_build_defer_index.js:2147:109
>  2942 11-13 18:50:36.474   269   269 D GeckoConsole: atc_changeTransitionState@app://system.gaiamobile.org/gaia_build_defer_index.js:2030:123
>  2943 11-13 18:50:36.474   269   269 D GeckoConsole: atc_handleEvent@app://system.gaiamobile.org/gaia_build_defer_index.js:2045:753
>  2944 11-13 18:50:36.474   269   269 D GeckoConsole: aw_broadcast@app://system.gaiamobile.org/gaia_build_defer_index.js:2147:350
>  2945 11-13 18:50:36.474   269   269 D GeckoConsole: atc_do_closing/this._closingTimeout<@app://system.gaiamobile.org/gaia_build_defer_index.js:2032:1
>  2946 11-13 18:50:36.474   269   269 D GeckoConsole:
>  2947 11-13 18:50:36.474   269   269 D GeckoConsole:     at .warn (app://system.gaiamobile.org/js/sim_lock_manager.js:164:6)

Alive, is it normal that I always get this, when SIM PIN dialog is displayed and when it's not? This is code you touched recently, but maybe you kept the logic from before :)

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 44 • 10 years ago

(In reply to Alexandre LISSY :gerard-majax from comment #43)
> Not sure if it's related, but I see this when adding some debug and
> reproducing on my ZR:
> 
> >  2936 11-13 18:50:36.474   269   269 D GeckoConsole: Content JS DEBUG: [DAFUK] SimLockManager: Already displayed.
> >  2937 11-13 18:50:36.474   269   269 D GeckoConsole:     at .warn (app://system.gaiamobile.org/js/sim_lock_manager.js:163:6)
> >  2938 11-13 18:50:36.474   269   269 D GeckoConsole: Content JS DEBUG: [DAFUK] SimLockManager: stack: .warn@app://system.gaiamobile.org/js/sim_lock_manager.js:164:58
> >  2939 11-13 18:50:36.474   269   269 D GeckoConsole: sl_showIfLocked@app://system.gaiamobile.org/js/sim_lock_manager.js:184:9
> >  2940 11-13 18:50:36.474   269   269 D GeckoConsole: lockscreenOnClosed@app://system.gaiamobile.org/js/sim_lock_manager.js:124:11
> >  2941 11-13 18:50:36.474   269   269 D GeckoConsole: AppWindow.prototype.publish@app://system.gaiamobile.org/gaia_build_defer_index.js:2147:109
> >  2942 11-13 18:50:36.474   269   269 D GeckoConsole: atc_changeTransitionState@app://system.gaiamobile.org/gaia_build_defer_index.js:2030:123
> >  2943 11-13 18:50:36.474   269   269 D GeckoConsole: atc_handleEvent@app://system.gaiamobile.org/gaia_build_defer_index.js:2045:753
> >  2944 11-13 18:50:36.474   269   269 D GeckoConsole: aw_broadcast@app://system.gaiamobile.org/gaia_build_defer_index.js:2147:350
> >  2945 11-13 18:50:36.474   269   269 D GeckoConsole: atc_do_closing/this._closingTimeout<@app://system.gaiamobile.org/gaia_build_defer_index.js:2032:1
> >  2946 11-13 18:50:36.474   269   269 D GeckoConsole:
> >  2947 11-13 18:50:36.474   269   269 D GeckoConsole:     at .warn (app://system.gaiamobile.org/js/sim_lock_manager.js:164:6)
> 
> Alive, is it normal that I always get this, when SIM PIN dialog is displayed
> and when it's not? This is code you touched recently, but maybe you kept the
> logic from before :)

When lockscreen is unlocked (even it's not enabled), SimLockManager will get unlock event to show the dialog. I don't see anything wrong in your log, but as comment 40, SimManager seems a gecko object? Is it possible when lockscreen unlocked the sim state is still not ready yet?

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 45 • 10 years ago

(In reply to Alexandre LISSY :gerard-majax from comment #38)
> Performing several reset-gaia with hard-coded lockscreen disabled:
>  - on v2.1, I always get SIM PIN dialog
>  - on master, I never get SIM PIN dialog

My lockscreen is disabled (by DEVICE_DEBUG=1). I could get sim pin dialog always. (I have only 1 SIM though)

	:gerard-majax Reporter
	Comment 46 • 10 years ago

Alive, just to be clear, what I'm wondering about is "SimLockManager: Already displayed."

I see this in both cases. That makes sense when the SIM PIN dialog is really displayed, but that does not make a lot of sense when it is not displayed.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 47 • 10 years ago

(In reply to Alexandre LISSY :gerard-majax from comment #46)
> Alive, just to be clear, what I'm wondering about is "SimLockManager:
> Already displayed."
> 
> I see this in both cases. That makes sense when the SIM PIN dialog is really
> displayed, but that does not make a lot of sense when it is not displayed.

For sure: "Already displayed but the user cannot see it" is a bug.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 48 • 10 years ago

Well, I am seeing this bug in master flame with 2 locked SIM card. And it's just my guess: the second card is detected before the first card so we just show the 2nd card.

I don't have a good idea about how to fix it yet. Wait until 2 sim slots are detected is a bad idea because that will slow down startup time.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 49 • 10 years ago

Update: what I am seeing is, the 2nd SIM PIN UI is displayed at bootup than 1st SIM PIN.

The root cause is the simslot-cardstatechange of the second sim slot is got before the first sim slot. And we will show the corresponding sim slot on the change event. My proposed fix will be showing the first sim pin anyway if it's locked. I will provide a patch in another bug because it's not the same as the symptom described in this bug.

	:gerard-majax Reporter
	Comment 50 • 10 years ago

Thanks alive. I did a quick hack on my ZR, and after pushing a real gecko update, I don't reproduce the issue anymore:

> diff --git a/apps/system/js/sim_lock_manager.js b/apps/system/js/sim_lock_manager.js
> index 8b19103..49f1929 100644
> --- a/apps/system/js/sim_lock_manager.js
> +++ b/apps/system/js/sim_lock_manager.js
> @@ -176,8 +181,8 @@
>        }
>  
>        if (this.simLockSystemDialog.visible) {
> -        this.warn('Already displayed.');
> -        return false;
> +        this.warn('Already displayed: BUT WE DONT CARE HAHAHA§§§§');
> +        // return false;
>        }
>  
>        // FTU has its specific SIM PIN UI

So I still see the warning in my logs, but now the SIM PIN is properly displayed after the first boot after upgrade.

	:gerard-majax Reporter
	Comment 51 • 10 years ago

Booting, unlocking the screen several times:
> boot-simpin_warn4.log:11-14 15:31:30.314   268   268 D GeckoConsole: Content JS DEBUG: SimLockSystemDialog: DING DONG 
> boot-simpin_warn4.log:11-14 15:31:30.314   268   268 D GeckoConsole: Content JS DEBUG: SimLockSystemDialog: _visible=false 
> boot-simpin_warn4.log:11-14 15:31:30.635   268   268 D GeckoConsole: Content JS DEBUG: SimLockSystemDialog: visible(): this._visible=false 
> boot-simpin_warn4.log:11-14 15:31:30.635   268   268 D GeckoConsole: Content JS DEBUG: SimLockSystemDialog: show(): this._visible=true 
> boot-simpin_warn4.log:11-14 15:31:51.785   268   268 D GeckoConsole: Content JS DEBUG: SimLockSystemDialog: visible(): this._visible=true 
> boot-simpin_warn4.log:11-14 15:34:04.759   268   268 D GeckoConsole: Content JS DEBUG: SimLockSystemDialog: visible(): this._visible=true 
> boot-simpin_warn4.log:11-14 15:34:19.513   268   268 D GeckoConsole: Content JS DEBUG: SimLockSystemDialog: visible(): this._visible=true 

So it looks like everything goes well in SimLockSystemDialog and that LockScreen does its job (YES§§)

	:gerard-majax Reporter
	Comment 52 • 10 years ago

Two interesting facts that I noticed yesterday and that I could consistently reproduce today:
 - At some point, I can get the SIM PIN dialog visible to the user WITHOUT rebooting the device, and when this happens, the UI is misplaced regarding to the software home button: Skip and Ok buttons are hidden behind the SHB.
 - This "At some point" gets triggered each time I do connect my WebIDE instance to my device: I wanted to do so to access the DOM state and see where the SIM PIN dialog window was ... But as soon as I connect via WebIDE, this makes the dialog appearing. Hard to debug :)

Etienne or Alive, if anything comes to your mind ... :)

	:gerard-majax Reporter
	Comment 53 • 10 years ago

Some debug after reproducing the issue ...

	:gerard-majax Reporter
	Comment 54 • 10 years ago

Patch that generates the debug log exposed in attachment 8523520 [details].

	:gerard-majax Reporter
	Comment 55 • 10 years ago

Grepping the log, we can see:
 1. proper detection of SIM card
 2. proper trigger of the request focus ('system-dialog-requestfocus' event) by SimLockSystemDialog
 3. registration of 'system-dialog-requestfocus' handler by SystemDialogManager

But we can also see from the code that step 3 happens after step 2. This could be the race condition we are indeed facing ?

	:gerard-majax Reporter
	Comment 56 • 10 years ago

And given that bootstrap.js triggers SystemDialogManager in registerGlobalEntries() code, which is triggered ONCE we have applicationready event, this would make sense: new build triggers dom/apps/Webapps* update code path, which makes this event coming a bit late.

	:gerard-majax Reporter
	Comment 57 • 10 years ago

Doing the same focus, but after doing a reboot. This time, we see that the SystemDialogManager code does register events before the sim handling code triggers its events. Hence, dialog is shown.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 58 • 10 years ago

(In reply to Alexandre LISSY :gerard-majax from comment #52)
> Two interesting facts that I noticed yesterday and that I could consistently
> reproduce today:
>  - At some point, I can get the SIM PIN dialog visible to the user WITHOUT
> rebooting the device, and when this happens, the UI is misplaced regarding
> to the software home button: Skip and Ok buttons are hidden behind the SHB.
>  - This "At some point" gets triggered each time I do connect my WebIDE
> instance to my device: I wanted to do so to access the DOM state and see
> where the SIM PIN dialog window was ... But as soon as I connect via WebIDE,
> this makes the dialog appearing. Hard to debug :)
> 
> Etienne or Alive, if anything comes to your mind ... :)

I noticed SWH is enabled each time I boot with a SIM PIN, but I don't know what happens.
ni michael to see if he has already knew.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 59 • 10 years ago

I am a little confused about what you are trying to resolve since comment 50.
If the issue is "Sometimes SIM PIN shows to the user but it should not" could you please update the bug summary?

	Marek Raida
	Comment 60 • 10 years ago

I'm able to reproduce with 50% probability, scenario:
- Flame, one SIM only
- downloaded OTA, updating and restarting
- PIN is not asked after reboot

	Michael Henretty [:mikehenrty][:mhenretty]
	Comment 61 • 10 years ago

(In reply to Alexandre LISSY :gerard-majax from comment #52)
> Two interesting facts that I noticed yesterday and that I could consistently
> reproduce today:
>  - At some point, I can get the SIM PIN dialog visible to the user WITHOUT
> rebooting the device, and when this happens, the UI is misplaced regarding
> to the software home button: Skip and Ok buttons are hidden behind the SHB.
>  - This "At some point" gets triggered each time I do connect my WebIDE
> instance to my device: I wanted to do so to access the DOM state and see
> where the SIM PIN dialog window was ... But as soon as I connect via WebIDE,
> this makes the dialog appearing. Hard to debug :)

I can't speak to why connecting webIDE makes the SIM PIN dialog show up. But it seems really strange that the Skip and OK buttons are hidden behind the SHB here, since whenever we show that dialog we manually update its height with respect to SHB [1]. We must be hitting a code path that doesn't call `show`.

1.) https://github.com/mozilla-b2g/gaia/blob/9b274e0101506fc76afa5e0808d4dceb4ee9568b/apps/system/js/system_dialog.js#L189


(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #58)
> I noticed SWH is enabled each time I boot with a SIM PIN, but I don't know
> what happens.
> ni michael to see if he has already knew.

I'm not sure what you are asking me.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 62 • 10 years ago

Lemme know if this works!

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 63 • 10 years ago

Not a 2.1 issue anymore.

	:gerard-majax Reporter
	Comment 64 • 10 years ago

Comment on attachment 8524387 [details] [review]
Async showing system dialog before system dialog manager starts

It does not work :(

$ egrep 'SimLock|SimLockSystemDialog:|SystemDialogManager:' boot-simpin_warn8.log
11-18 10:35:45.576   260   260 D GeckoConsole: Content JS DEBUG: SystemDialogManager: DING DONG 
11-18 10:35:47.668   260   260 D GeckoConsole: Content JS DEBUG: [DAFUK] SimLockManager: dialog not ready. 
11-18 10:35:47.668   260   260 D GeckoConsole: Content JS DEBUG: [DAFUK] SimLockManager: stack: .warn@app://system.gaiamobile.org/js/sim_lock_manager.js:164:58
11-18 10:35:50.030   260   260 D GeckoConsole: Content JS DEBUG: SystemDialogManager: start(): E 
11-18 10:35:50.030   260   260 D GeckoConsole: Content JS DEBUG: SystemDialogManager: start(): addEventListener('system-dialog-created') 
11-18 10:35:50.030   260   260 D GeckoConsole: Content JS DEBUG: SystemDialogManager: start(): addEventListener('system-dialog-show') 
11-18 10:35:50.030   260   260 D GeckoConsole: Content JS DEBUG: SystemDialogManager: start(): addEventListener('system-dialog-hide') 
11-18 10:35:50.030   260   260 D GeckoConsole: Content JS DEBUG: SystemDialogManager: start(): addEventListener('simlockshow') 
11-18 10:35:50.030   260   260 D GeckoConsole: Content JS DEBUG: SystemDialogManager: start(): addEventListener('simlockhide') 
11-18 10:35:50.030   260   260 D GeckoConsole: Content JS DEBUG: SystemDialogManager: start(): addEventListener('system-resize') 
11-18 10:35:50.030   260   260 D GeckoConsole: Content JS DEBUG: SystemDialogManager: start(): addEventListener('system-dialog-requestfocus') 
11-18 10:35:50.040   260   260 D GeckoConsole: Content JS DEBUG: SystemDialogManager: start(): addEventListener('home') 
11-18 10:35:50.040   260   260 D GeckoConsole: Content JS DEBUG: SystemDialogManager: start(): addEventListener('holdhome') 
11-18 10:35:50.040   260   260 D GeckoConsole: Content JS DEBUG: SystemDialogManager: start(): addEventListener('mozChromeEvent') 
11-18 10:35:50.050   260   260 D GeckoConsole: Content JS DEBUG: SystemDialogManager: start(): X 
11-18 10:35:56.216   260   260 I GeckoConsole: Content JS LOG: [System][11.336]SimLockManager.isActive 
11-18 10:36:19.709   260   260 I GeckoDump: [system] [SimLockManager][35.032] handling lockscreen-request-unlock
11-18 10:36:20.380   260   260 D GeckoConsole: Content JS DEBUG: [DAFUK] SimLockManager: dialog not ready. 
11-18 10:36:20.380   260   260 D GeckoConsole: Content JS DEBUG: [DAFUK] SimLockManager: stack: .warn@app://system.gaiamobile.org/js/sim_lock_manager.js:164:58
11-18 10:36:20.580   260   260 I GeckoConsole: Content JS LOG: [System][35.776]SimLockManager.isActive 
11-18 10:36:25.395   260   260 I GeckoConsole: Content JS LOG: [System][39.581]SimLockManager.isActive 
11-18 10:36:26.246   260   260 I GeckoDump: [system] [SimLockManager][41.570] handling lockscreen-request-unlock
11-18 10:36:26.846   260   260 D GeckoConsole: Content JS DEBUG: [DAFUK] SimLockManager: dialog not ready. 
11-18 10:36:26.846   260   260 D GeckoConsole: Content JS DEBUG: [DAFUK] SimLockManager: stack: .warn@app://system.gaiamobile.org/js/sim_lock_manager.js:164:58

	:gerard-majax Reporter
	Comment 65 • 10 years ago

Full log when applying your patch

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 66 • 10 years ago

11-18 10:35:50.040   260   260 I GeckoConsole: Content JS LOG: [System][5.095]SystemDialogManager is registering service: [showSystemDialog] 

This time system dialog manager is started before the sim lock

11-18 10:36:20.380   260   260 D GeckoConsole: Content JS DEBUG: [DAFUK] SimLockManager: dialog not ready. 


What does not ready mean?

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 67 • 10 years ago

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #66)
> 11-18 10:35:50.040   260   260 I GeckoConsole: Content JS LOG:
> [System][5.095]SystemDialogManager is registering service:
> [showSystemDialog] 
> 
> This time system dialog manager is started before the sim lock
> 
> 11-18 10:36:20.380   260   260 D GeckoConsole: Content JS DEBUG: [DAFUK]
> SimLockManager: dialog not ready. 
> 
> 
> What does not ready mean?

Uh, it's from simLockManager.
So the system dialog is not instantiated before the simslot manager is ready this time!

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 68 • 10 years ago

Comment on attachment 8524387 [details] [review]
Async showing system dialog before system dialog manager starts

Let's try round2!

	:gerard-majax Reporter
	Comment 69 • 10 years ago

Comment on attachment 8524387 [details] [review]
Async showing system dialog before system dialog manager starts

Same :(.

	:gerard-majax Reporter
	Comment 70 • 10 years ago

So, indeed, delaying applicationready status does 100% reproduce the issue.

	Gregor Wagner [:gwagner]
	Comment 71 • 10 years ago

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #63)
> Not a 2.1 issue anymore.

Why? comment 15 is a video from 2.1

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 72 • 10 years ago

(In reply to Gregor Wagner [:gwagner] from comment #71)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #63)
> > Not a 2.1 issue anymore.
> 
> Why? comment 15 is a video from 2.1

Things totally mess up. Read through all the comments and based on the discussion with Alex I got the information the original issue reported here is gone in v2.1.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 73 • 10 years ago

[Blocking Requested - why for this release]:
The last comments Alex had address is another issue in master, given this is reproduced in v2.1 in some people's device, put the flag back and deassign myself.

Alberto are you available to work on this? Thanks in advance.

	Gregor Wagner [:gwagner]
	Comment 74 • 10 years ago

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #73)
> [Blocking Requested - why for this release]:
> The last comments Alex had address is another issue in master, given this is
> reproduced in v2.1 in some people's device, put the flag back and deassign
> myself.
> 
> Alberto are you available to work on this? Thanks in advance.

Are we sure we have 2 separate issues here? If so, we need 2 separate bugs and fixing 2.1 has higher priority. I let developers working on this issues decide how they want to organize the bugs.

Seems like 2.1 has an issue related to RIL and dual-SIM. Arthur has the expertise for DSDS and most RIL developers are also based in Taipei. Tim, can you drive this?

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 75 • 10 years ago

(In reply to Gregor Wagner [:gwagner] from comment #14)
> (In reply to Alexandre LISSY :gerard-majax from comment #12)
> > So I checked with the patch from bug 976497: no change. SIM card is indeed
> > properly detected.
> > Greg, how can I enable much debug in lockscreen interactions with SIM PIN to
> > try to find something ?
> > 
> > Besides, Gregor *do* reproduce something that looks very close to this bug
> > on Flame.
> 
> I see some race-condition on my flame (fresh 2.1 build from today)
> I have 2 PIN prodected SIMs in my flame. After a reboot and unlocking the
> lock-screen I only see 9 out of 10 times the PIN dialog for the 2nd SIM.
> Once I am on the home-screen and open the dialer app I get asked to enter
> the PIN for the 1st SIM.

For this issue, I am sure it is caused by:
when system is booted, we will get 2 iccdetected for each sim slot.
Sometimes the second iccdetected which will trigger cardstatechange is fired before the 1st one.
So sim lock dialog is shown for the second sim because 1st sim is not detected yet. I don't know how to fix this because delaying the time to show sim lock dialog will bring us additional boot time. If we treat it is a regression, it may be coming from the gecko because the timing of the event is controlled by them.

For another issue described in the bug title:
I never see it: 2nd sim is not asked after skipping 1st sim. No, never happen to me.

For sim dialog is not shown as bug 1098334:
I believe it's due to the loading sequence change coming from bug 1062819 landed in master, but now I am not sure because my patch does not fix Alex' problem.

So what are we trying to fix? Please be accurate.

	Alberto Pastor [:albertopq] Assignee
	Comment 76 • 10 years ago

I'm a little bit confused by the comments here, but I'll try to help on this :)

	:gerard-majax Reporter
	Comment 77 • 10 years ago

People, please focus on comment 54, comment 55, comment 56 and command 57. Please also note that attachment 8524631 [details] will help reproducing the issue consistently.

	:gerard-majax Reporter
	Comment 79 • 10 years ago

Also, please note that moving the SystemDialogManager instanciation out of the dependency on applicationsready like this will make the present bug "fixed": I get SIM PIN dialog, but after unlcking, the keypad does not disappear until I focus and leave the focus of another input field.

diff --git a/apps/system/js/bootstrap.js b/apps/system/js/bootstrap.js
index bf378bd..61be371 100644
--- a/apps/system/js/bootstrap.js
+++ b/apps/system/js/bootstrap.js
@@ -67,9 +67,6 @@ window.addEventListener('load', function startup() {
       window.suspendingAppPriorityManager = new SuspendingAppPriorityManager();
     }
 
-    /** @global */
-    window.systemDialogManager = window.systemDialogManager ||
-      new SystemDialogManager();
 
     /** @global */
     window.lockScreenWindowManager = new window.LockScreenWindowManager();
@@ -190,6 +187,8 @@ window.addEventListener('load', function startup() {
   window.softwareButtonManager = new SoftwareButtonManager();
   window.softwareButtonManager.start();
   window.sourceView = new SourceView();
+  /** @global */
+  window.systemDialogManager = window.systemDialogManager || new SystemDialogManager();
   window.taskManager = new TaskManager();
   window.taskManager.start();
   window.ttlView = new TTLView();

	:gerard-majax Reporter
	Comment 80 • 10 years ago

With this PR applied, I don't reproduce the issue anymore on my Xperia ZR and on my Flame. I do see buttons partly hidden by the software home button, but that's another story.

	Alberto Pastor [:albertopq] Assignee
	Comment 81 • 10 years ago

Thanks :gerard_majax. I'll add some unit tests before sending the r?, but the patch should be ready today

	Alberto Pastor [:albertopq] Assignee
	Comment 82 • 10 years ago

Comment on attachment 8526051 [details] [review]
Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/26329

:)

	Kevin Grandon :kgrandon
	Comment 83 • 10 years ago

Comment on attachment 8526051 [details] [review]
Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/26329

So I don't have two SIMs that I can test with here, but the code is relatively straightforward so I don't mind reviewing it. Alberto - I left a few comments on github, could you address and re-flag me for review? Thanks!

	Kevin Grandon :kgrandon
	Comment 84 • 10 years ago

Comment on attachment 8526051 [details] [review]
Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/26329

I am unable to test this currently, but the code looks fine to me. I am curious why applications.ready is needed for the sim dialog, can you leave a quick comment in the bug as to the root cause as to why it's needed? I tried reading through the bug, but I couldn't find the exact reasoning.

	Alberto Pastor [:albertopq] Assignee
	Comment 85 • 10 years ago

The problem is that we are receiving iccstatechange events before all the listeners for dialogs have been set. We need to discard those events until the applicationready event is received, and then we'll retry showing the dialogs when unlocking. If we don't do that, it will think that the dialog is visible (dialog.visible = true) although the UI is not there. We need to fix that problem when the lockscreen is not there. I created 1102965 for tracking that.

	Alberto Pastor [:albertopq] Assignee
	Comment 86 • 10 years ago

master: https://github.com/mozilla-b2g/gaia/commit/2cc24e5892c3e84c6fef56ee6279cfb155e538a2

	Alberto Pastor [:albertopq] Assignee
	Comment 87 • 10 years ago

Comment on attachment 8526051 [details] [review]
Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/26329

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): -
[User impact] if declined: SIM PIN dialog is not shown after restart
[Testing completed]: Added unit tests. All previous UI tests passing
[Risk to taking this patch] (and alternatives if risky): I think there is no high risk on this. We are dismissing events until the device is ready. We were not handling those events properly anyways, so I cannot think on any side effect.
[String changes made]: -

	Ryan VanderMeulen [:RyanVM]
	Comment 88 • 10 years ago

Needs rebasing for v2.1 uplift.

	Alberto Pastor [:albertopq] Assignee
	Comment 89 • 10 years ago

This patch is not applicable to v2.1. Most of the files changed doesn't exist on 2.1. Gregor's comment on #14 is probably more related to 1102965 than this one. Gregor, are you having problems on 2.1 with the Screen Lock enabled or disabled?

	Brogan Zumwalt [Inactive]
	Comment 90 • 10 years ago

Issue still occurs on Flame 2.2

With two locked SIM cards, Gregors STR from Comment 14 reproduces. Rebooting phone shows SIM 2 passcode prompt. SIM 1 passcode prompt only shows when user launches an application like dialer from the homescreen.

Repro rate stands at 4 out of 6 attempts.

The two non-consecutive times where the issue did not occur both the SIM 1 and SIM 2 passcode appear after unlocking screen.

Device: Flame 2.2  (319mb)(Kitkat Base)(Shallow Flash)
Build ID: 20141126040207
Gaia: 41b7be7c67167f367c3c4982ff08651d55455373
Gecko: 7bcc6573d204
Version: 36.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

	Alberto Pastor [:albertopq] Assignee
	Comment 91 • 10 years ago

(In reply to Brogan Zumwalt [:BroganZ] from comment #90)
> Issue still occurs on Flame 2.2
> 
> With two locked SIM cards, Gregors STR from Comment 14 reproduces. Rebooting
> phone shows SIM 2 passcode prompt. SIM 1 passcode prompt only shows when
> user launches an application like dialer from the homescreen.
> 
> Repro rate stands at 4 out of 6 attempts.
> 
> The two non-consecutive times where the issue did not occur both the SIM 1
> and SIM 2 passcode appear after unlocking screen.
> 
> Device: Flame 2.2  (319mb)(Kitkat Base)(Shallow Flash)
> Build ID: 20141126040207
> Gaia: 41b7be7c67167f367c3c4982ff08651d55455373
> Gecko: 7bcc6573d204
> Version: 36.0a1 (2.2)
> Firmware Version: v188-1
> User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

The issue you are describing here will be fixed by Bug 1102965. The current bug was causing not seeing any SIM Pin dialog at all. The fact that you see only the second one, is a different issue so this bug should be verified by checking that at least 1 SIM pin dialog is shown always. Sorry about this, it wasn't really clear in the bug.

	Alberto Pastor [:albertopq] Assignee
	Comment 92 • 10 years ago

Clearing ni as the SIM 2 showing earlier than 1 is happening in both Screenlock enabled and disabled cases. Fixed by Bug 1102965.

	sarsenyev
	Comment 93 • 10 years ago

Verified the issue is fixed on 2.2 Flame
SIM card is detected and the PIN dialog appears for both SIM cards on start up

"Flame 2.2

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141202040207
Gaia: 725685831f5336cf007e36d9a812aad689604695
Gecko: 2c9781c3e9b5
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
===================================================================
Leaving verifyme for 2.1 patch uplift

	KTucker [:KTucker][Inactive 3/4/2016]
	Comment 94 • 10 years ago

Brogan, can you verify the issue in comment 90 has been fixed by the fix for bug 1102965.

	Brogan Zumwalt [Inactive]
	Comment 95 • 10 years ago

It appears that sarsenyev beat me to it in comment 93

	Brogan Zumwalt [Inactive]
	Comment 96 • 10 years ago

For further clarification, the issue I saw occurring in comment 90 no longer occurs on Flame 2.2

Rebooting phone with 2 sim locked sim cards shows both sim 1 and sim 2 passcode screens on reboot. 

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141203040207
Gaia: 725685831f5336cf007e36d9a812aad689604695
Gecko: 2c9781c3e9b5
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

	Ryan VanderMeulen [:RyanVM]
	Comment 97 • 10 years ago

Can we please update the v2.1 blocking status?

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 98 • 10 years ago

I didn't follow...if it's affected then let it be.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 99 • 10 years ago

(In reply to Alive Kuo [:alive][NEEDINFO!][PDXww until 12/5] from comment #98)
> I didn't follow...if it's affected then let it be.

Read the patch I think it's master only because v2.1 does not have lazy loaded sim slot manager.
Hi Alberto, could you please specify why this affects v2.1 as well? And please make a v2.1 patch if really affected.

	Alberto Pastor [:albertopq] Assignee
	Comment 100 • 10 years ago

Despite the bug is still valid in 2.1 (I can repro it with current 2.1, after applying attachment 8524631 [details]), this patch is not applicable. I think the best approach would be having a 2.1 only patch that reproduces this fix but in the 2.1 codebase.

	Alberto Pastor [:albertopq] Assignee
	Comment 103 • 10 years ago

v2.1: https://github.com/mozilla-b2g/gaia/commit/155424d51cf9bb2ea41dc6667f94741f82f35bc0

	Shally Li（leave from Mozilla）
	Comment 104 • 10 years ago

This issue has been failed verified on Flame v2.1.
See attachments:verify_v2.1.mp4 and logcat_0622.txt
Reproduce rate: 4/5.

STR:
1.Run "./flash.sh".
2.Tap "Next" in language page of FTU.
**The SIM1 PIN and SIM2 PIN code will be asked.
3.Tap "Skip" SIM1 and SIM2 PIN code,and then through FTU to Homescreen.
**There is no SIM signal or other SIM messages on title bar.
**It displays "The SIM card is locked" when user go to Settings->SIM Manager/Call Settings/Cellular & Data.
4.Tap Power button to lockscreen,and unlock screen.
**The SIM1 PIN and SIM2 PIN code will be asked and skip them.
5.Restart device and unlock screen.
**SIM2 PIN code will be asked and input SIM PIN code.
6.Open Messages app
**SIM1 PIN code will be asked and user can input PIN code.

Flame 2.1 build:
Gaia-Rev        38e17b0219cbc50a4ad6f51101898f89e513a552
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a
Build-ID        20141205001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141205.035305
FW-Date         Fri Dec  5 03:53:16 EST 2014
Bootloader      L1TC00011880

Flame 2.1  build:
Gaia-Rev        c226db212db4d824c09617cd6dc407b2d4258d9b
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/cf8bebfa4703
Build-ID        20141209170126
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141209.212104
FW-Date         Tue Dec  9 21:21:15 EST 2014
Bootloader      L1TC00011880

	Alberto Pastor [:albertopq] Assignee
	Comment 107 • 10 years ago

Sorry, my bad, missing one line on the patch. https://github.com/mozilla-b2g/gaia/pull/26687/files

I'll backout and reland. I'll post here as soon as it lands to re-verify.

Thanks!

	Alberto Pastor [:albertopq] Assignee
	Comment 108 • 10 years ago

backout: https://github.com/albertopq/gaia/commit/5d6dd54428d0dabf79165bf8e546478d6937a466

v2.1: https://github.com/albertopq/gaia/commit/a58ab60227f9962cfde76c38e9e7d294a0fbb08d

Shally, could you please reverify?

	Shally Li（leave from Mozilla）
	Comment 109 • 10 years ago

Hi Alberto,
  This bug has been successfully reverified on Flame v2.1.
  See attachment: verified_v2.1.mp4.
  Reproduce rate: 0/3.
  STR: please refer Comment 104.

Flame v2.1 build:
Gaia-Rev        97873dca486abf4162a3345e71b375806937bdec
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/07a4ca3db40a
Build-ID        20141210161206
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141210.193802
FW-Date         Wed Dec 10 19:38:12 EST 2014
Bootloader      L1TC00011880

	Alberto Pastor [:albertopq] Assignee
	Comment 111 • 10 years ago

Not sure if you need any info for me. Reflag me if that's the case.

Thanks for re-verifying, Shally!

	Shally Li（leave from Mozilla）
	Comment 112 • 10 years ago

Just let you know that this bug has been successfully verified.

Thank you!

	siiaceon
	Comment 113 • 9 years ago

Side Effect: Only SIM Slot2 insert SIM which pin enabled, not Prompt.

	Shally Li（leave from Mozilla）
	Comment 114 • 9 years ago

(In reply to siiaceon from comment #113)
> Side Effect: Only SIM Slot2 insert SIM which pin enabled, not Prompt.

Yes, I has submitted a new bug 1110660.

Thanks.

	siiaceon
	Comment 115 • 9 years ago

OK, thanks.

	Yang Yang
	Comment 116 • 9 years ago

(In reply to Alberto Pastor [:albertopq] from comment #108)
> backout:
> https://github.com/albertopq/gaia/commit/
> 5d6dd54428d0dabf79165bf8e546478d6937a466
> 
> v2.1:
> https://github.com/albertopq/gaia/commit/
> a58ab60227f9962cfde76c38e9e7d294a0fbb08d
> 
> Shally, could you please reverify?


Alberto, I do not understand these changes below:

 // Always showing the first slot first.
- if (!this._alreadyShown && index > 1) {
+ if (!this._alreadyShown && index > 0) {
return false;
}

There chang 1 to 0, means index 1 should be return false, and index 0 not return?

if what i guess before is right, then we find a problem: if there is only sim2 is locked, the sim unlock
dialog will never open because the case (!this._alreadyShown && index > 0) is always be true.

I want to know why you add the case (!this._alreadyShown && index > 0).

Thank you very much for your kindly reply.

	Alberto Pastor [:albertopq] Assignee
	Comment 117 • 9 years ago

(In reply to Yang Yang from comment #116)
> (In reply to Alberto Pastor [:albertopq] from comment #108)
> > backout:
> > https://github.com/albertopq/gaia/commit/
> > 5d6dd54428d0dabf79165bf8e546478d6937a466
> > 
> > v2.1:
> > https://github.com/albertopq/gaia/commit/
> > a58ab60227f9962cfde76c38e9e7d294a0fbb08d
> > 
> > Shally, could you please reverify?
> 
> 
> Alberto, I do not understand these changes below:
> 
>  // Always showing the first slot first.
> - if (!this._alreadyShown && index > 1) {
> + if (!this._alreadyShown && index > 0) {
> return false;
> }
> 
> There chang 1 to 0, means index 1 should be return false, and index 0 not
> return?
> 
> if what i guess before is right, then we find a problem: if there is only
> sim2 is locked, the sim unlock
> dialog will never open because the case (!this._alreadyShown && index > 0)
> is always be true.
> 
> I want to know why you add the case (!this._alreadyShown && index > 0).
> 
> Thank you very much for your kindly reply.

If there is only 1 sim locked, this._alreadyShown should be false, isn't it? I'm talking from the top of my head, so let me take a look today.

The reason of that check is always showing the sim1 pin dialog before the sim2 if both are locked. Note that sometimes we receive sim status changes from the sim2 before the sim1. That condition tries to always show them in order.

Thanks!

	Yang Yang
	Comment 118 • 9 years ago

(In reply to Alberto Pastor [:albertopq] from comment #117)

> 
> If there is only 1 sim locked, this._alreadyShown should be false, isn't it?
   
  Yes, if there is only sim2 locked, this._alreadyShown will always be false.


> The reason of that check is always showing the sim1 pin dialog before the
> sim2 if both are locked. Note that sometimes we receive sim status changes
> from the sim2 before the sim1. That condition tries to always show them in
> order.
> 
> Thanks!

  I know the reason now, thank you for your reply.
  
  I have a patch to resolve the only 1 sim locked issue, and i have attach it in bug 1110660,
can you review it for me, thank you.