876637 - [DIALER] If you place a call to 112 with SIM security enabled while in airplane mode, PIN code is required

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Dialer, defect)

Description

[Carlos Martínez Toral [:carlosmartinez]]

Attachment: Weird attention screen when placing a call to 112 with SIM security while in airplane mode

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)

Comment 1

[Germán Toro del Valle (:gtorodelvalle)]

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

Comment 2

[Leo]

I checked this, but I can't see the PIN code request. but the weired screen is shown.

Comment 3

[Germán Toro del Valle (:gtorodelvalle)]

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!

Comment 4

[Etienne Segonzac (:etienne)]

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?)

Comment 5

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

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.

Comment 6

[Germán Toro del Valle (:gtorodelvalle)]

Absolutely, Alive, this bug and even myself are all yours... :-p

Comment 7

[Carlos Martínez Toral [:carlosmartinez]]

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

Comment 8

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

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.

Comment 9

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

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

Comment 10

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

Attachment: Proposal: Utilize callscreen open/close event to discard the cardstatechange event in sim lock.

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.

Comment 11

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

Attachment: Proposal: Utilize callscreen open/close event to discard the cardstatechange event in sim lock

revised ver.

Comment 12

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

Attachment: https://github.com/mozilla-b2g/gaia/pull/10286

See https://bugzilla.mozilla.org/attachment.cgi?id=760289&action=edit and previous comments.

Comment 13

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

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 :-/

Comment 14

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

master
https://github.com/mozilla-b2g/gaia/commit/91034b76d0dc45f58beea5596c1d945aadda826e

Comment 15

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

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

Comment 16

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

I will uplift manually.

Comment 17

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

v1-train
https://github.com/mozilla-b2g/gaia/commit/ea18de80fd04110756becaed214656642388401d

Comment 18

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

1.1hd: ea18de80fd04110756becaed214656642388401d