Closed Bug 876637 Opened 7 years ago Closed 7 years ago
[DIALER] If you place a call to 112 with SIM security enabled while in airplane mode, PIN code is required
51.86 KB, image/png
49.53 KB, image/png
87 bytes, text/html
Tested in unagi device with Gecko-39c9d5a.Gaia-4d10e12 from v1-train. STR: 1-Enable SIM security 2-Activate airplane mode 3-Open dialer and call 112 Expected result --> Call is placed without any further user interaction Actual result --> SIM pin is required and weird screen is shown above (see screenshot attached)
Hi! I just confirmed that this also happens in master: Gecko-c930902.Gaia-a6d5dc7 The PIN code is requested although in this case the keyboard is closed and consequently the attention screen for the outgoing emergency call is displayed correctly. Once the call is finished, the "Enter SIM PIN" screen is shown (since it was underneath the attention screen).
I checked this, but I can't see the PIN code request. but the weired screen is shown.
blocking-b2g: leo? → leo+
Target Milestone: --- → 1.1 QE3
Hi guys! I have been having a look at this bug and I do not foresee an easy fix :-( Right now, when in airplane mode, if the user dials an emergency number, according to bug 849185, the airplane mode is deactivated and the call is made. If the phone has the SIM Security activated and the correct PIN code has not been provided, this causes the mozMobileConnection.oncardstatechange to fire with a mozMobileConnection.cardState of 'pinRequired', and as an effect of this the PIN Security screen to show (see https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/sim_lock.js#L102). The problem is that there is no way to know right now if the 'pinRequired' card state change has been caused by the user (manually deactivating the airplane mode, in which case I guess we would like to show the user the PIN security screen, as we are doing right now) or by the platform (automatically deactivating the airplane mode due to an emergency call, in which case we do not want to show the user this PIN security screen). Trying to check if there is an ongoing emergency call before showing (or not) the PIN Security screen is not a good idea, in my opinion, because race conditions may arise :-) I thought about the possibility to check the WindowManager.getDisplayedApp() in case of a card state change to 'pinRequired' to try to disambiguate the cases we are interested in but but the combination of possible cases does not make it possible :-( A simple solution which comes to my mind is to be able to differentiate between 2 'pinRequired" card states, one when it has been caused by a user action and another one when has been caused by the platform (for the time being due to an emergency call). Inviting Etienne to comment on this in case I am missing something here ;-) Thanks!
This is a nice one :) In theory, I think the call screen attention screen should still the focus an cause the keyboard to hide (since the field in the SIM PIN dialog won't be focused anymore). But this is tricky, so I'll have to refer to Alive's knowledge of the situation. (Actually I wonder if maybe the keyboard hides after a small delay, ~5secs, Carlos?)
Hmm...this is really not an easy one. First of all we should try block the sim pin dialog when this case happens, the second thing worthy to go is avoid keyboard event sends/be manipulated to Window Manager. Both have a complex route, because attention screen(call screen) shouldn't join the event route in these two cases, and I wonder if we could write down the logic well described in comment 0. gtorodelvalle, if you don't mind I could take this. I think I could come up with a workaround-less way...as least I hope. etienne, thanks for flagging.
Absolutely, Alive, this bug and even myself are all yours... :-p
Assignee: gtorodelvalle → alive
(In reply to Etienne Segonzac (:etienne) from comment #4) > This is a nice one :) > > In theory, I think the call screen attention screen should still the focus > an cause the keyboard to hide (since the field in the SIM PIN dialog won't > be focused anymore). > > But this is tricky, so I'll have to refer to Alive's knowledge of the > situation. > > (Actually I wonder if maybe the keyboard hides after a small delay, ~5secs, > Carlos?) It´s never hidden, or at least, the call is placed before the keyboard hides.
After thinking, IMO the harmless and easiest approach is in sim lock, check telephony state. We don't need any SIM PIN unlock if the call is already establishing.
(In reply to Alive Kuo [:alive] from comment #8) > After thinking, IMO the harmless and easiest approach is in sim lock, check > telephony state. > We don't need any SIM PIN unlock if the call is already establishing. Unfortunately this doesn't work because 'cardstatechange' event is fired earlier than 'callstatechange' event. Event check AirplaneMode.enabled doesn't work because the airplane mode is automatically turned off. Hmm, really tricky one.
Proposal: See the execution sequence diagram. So we could dispatch callscreenopen/callscreenchange event from attentionscreen module(it already checks telephony permission there so it knows) to sim lock module to determine the next cardstatechange event should be discarded or not. During 'callscreenopen' to 'callscreenclose': ignore cardstatechange event. Otherwise shows the SIM PIN dialog if other condition is fulfilled.
Attachment #760287 - Attachment is obsolete: true
See https://bugzilla.mozilla.org/attachment.cgi?id=760289&action=edit and previous comments.
Attachment #760292 - Flags: review?(timdream)
Comment on attachment 760292 [details] https://github.com/mozilla-b2g/gaia/pull/10286 I consider this this is a said side effect for putting SIM card lock dialog in the System app; but until that changed we would just have to keep breaking the logic isolation like this :-/
Attachment #760292 - Flags: review?(timdream) → review+
I was not able to uplift this bug to v1-train. If this bug has dependencies which are not marked in this bug, please comment on this bug. If this bug depends on patches that aren't approved for v1-train, we need to re-evaluate the approval. Otherwise, if this is just a merge conflict, you might be able to resolve it with: git checkout v1-train git cherry-pick -x -m1 91034b76d0dc45f58beea5596c1d945aadda826e <RESOLVE MERGE CONFLICTS> git commit
I will uplift manually.
You need to log in before you can comment on or make changes to this bug.