964974 - [B2G][Airplane mode] Cannot turn on Airplane mode from Notification center during an active call

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[Salem Elkabule]

Attachment: Airplane mode log.txt

Description:
The user is unable to turn on airplane mode from the notification center during an active call

Repro Steps:
1) Updated Buri V1.3
2) Receive a call from a second device 
3) During the active call pull down the notification center 
4) Turn on Airplane mode 

Actual:
The user is unable to turn on airplane mode from the notification center during an active call

Expected:
The user should be able to turn on Airplane mode from the notification center

Environmental Variables
Device: buri V1.3 MOZ RIL
Build ID: 20140127004002
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/c40099a42c1f
Gaia: 25a45a836a4a21a30f63fa7b544b42e8b781180a
Platform Version: 28.0a2
Firmware Version: v1.2-device.cfg


Notes:
Repro frequency: 100%
See attached: video clip (http://www.youtube.com/watch?edit=vd&v=KGy8EyyHaDE), logcat

Comment 1

[Salem Elkabule]

I also tried turning on airplane mode from the settings application, the call will terminate after about 10 seconds. Then the airplane mode will be disabled automatically

Comment 2

[Salem Elkabule]

This issue does not reproduce on buri 1.2 

Environmental Variables
Device: buri V1.2 MOZ RIL 
Build ID: 20140127004002
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/d10e1f965d0c
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Platform Version: 26.0
Firmware Version: v1.2-device.cfg

The user is able to turn on airplane mode from the notification center in result to kill the call immediately

Comment 3

[Gregor Wagner [:gwagner]]

I think this is a feature.

Comment 4

[Jason Smith [:jsmith]]

(In reply to Gregor Wagner [:gwagner] from comment #3)
> I think this is a feature.

I certainly don't think so. comment 2 disproves that entirely - this worked fine on 1.2.

Comment 5

[Gregor Wagner [:gwagner]]

What should happen? Should we disconnect the call?

Comment 6

[Jason Smith [:jsmith]]

(In reply to Gregor Wagner [:gwagner] from comment #5)
> What should happen? Should we disconnect the call?

Technically yes, as you can't have a call active while airplane mode is active.

Comment 7

[Jason Smith [:jsmith]]

There's a bug here no matter what here though - the video showcases two different sets of behavior here in the notifications tray vs. settings app.

Comment 8

[Jason Smith [:jsmith]]

Given the fact that airplane mode pretty much always to work per certification requirements, I'm inclined to think this is a blocker, as I'm expecting to block certification.

Comment 9

[Jason Smith [:jsmith]]

Salem - Can you file a separate bug for the airplane mode setting getting disabled after being enabled?

Comment 10

[Preeti Raghunath(:Preeti)]

blocking for lacking of consistency

Comment 11

[Salem Elkabule]

I ran into this Bug #960706 and I think the issue might be related, I’m still investigating it, if it’s not related I will follow through with a new bug.

Comment 12

[jachen]

Based on today's triage it seems like this feature was in 1.2 but now not working in 1.3. I think that since no new behavior was spec-ed , we should return to the 1.2 capability.

Comment 13

[:gerard-majax]

I can't reproduce on Inari with Gecko master.

Comment 14

[:gerard-majax]

In the log, I see:
01-28 11:45:58.359: E/GeckoConsole(134): [JavaScript Error: "this._processNextMessage is not a function" {file: "jar:file:///system/b2g/omni.ja!/components/RadioInterfaceLayer.js" line: 672}]

That's not very cool :(. Could it be in fact a RIL bug ?

Comment 15

[:gerard-majax]

I don't reproduce this on Inari with v1.3 :(

Comment 16

[:gerard-majax]

But I do reproduce this on v1.3 with Buri.

Comment 17

[:gerard-majax]

E/GeckoConsole(  743): Content JS ERROR at app://communications.gaiamobile.org/dialer/js/telephony_helper.js:123 in errorCB: Unexpected error:  UnspecifiedError

Comment 18

[:gerard-majax]

I'm not sure that I actually really reproduce this issue ; in my case, the call is always correctly stopped.

Comment 19

[Salem Elkabule]

I've just retested this again, still can repro but apparently there are should be preconditions: 
 - my WiFi is off on device (the issue does not repro with WiFi On!)
 - my Deice has 2G(E) connection - I was unable to get it to repro on Buri with 3G (H)

New STR:
WIFI Off, Cellular data (E) edge
Repro Steps:
2) Receive a call from a second device 
3) During the active call pull down the notification center 
4) Turn on Airplane mode

Comment 20

[Matthew Vaughan]

Removing qawanted per comment 19. My device is a Buri with 3G (H) and I am unable to reproduce this issue using the 01/30/14 1.3 build.

Comment 21

[Salem Elkabule]

Created a new Bug #965886 for the Settings

Comment 22

[Matthew Vaughan]

This issue looks to have started reproducing on the 12/14/13 1.3 build. On builds before 12/14, it would take two taps on the Airplane mode button under the utility pull-down to enable Airplane mode. Once the mode was enabled, the call would end immediately.

- Works -
Device: Buri v1.3 MOZ RIL
BuildID: 20131213004002
Gaia: 888f9df5515a47d2f5806efee77485e05e1e5416
Gecko: dfae9c83bfbc
Version: 28.0a2
Firmware Version: V1.2-device.cfg

- Broken -
Device: Buri v1.3 MOZ RIL
BuildID: 20131214004003
Gaia: 37142f72c422120401dbc90e1f5e8f689576bb8e
Gecko: f81e19286279
Version: 28.0a2
Firmware Version: V1.2-device.cfg

Comment 23

[Etienne Segonzac (:etienne)]

I can reproduce the bug thanks to Alex, taking a look...

Comment 24

[Etienne Segonzac (:etienne)]

This looks *a lot* like a RIL issue.

Gaia successfully goes and call |.setRadioEnabled| on the mozMobileConnection [1].
And we get a DOMRequest back, but neither onsuccess nor onerror ever gets triggered.

Note that this is reproducible with wifi on or off, the key is to have and edge data connection.
FYI, the |radioState| is "enabled" when we launch the setRadioEnabled(false) request.

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/airplane_mode.js#L245-254

Comment 25

[Etienne Segonzac (:etienne)]

Ha, bug 963467 might also have the same root cause. A DOMRequest that won't return, the good thing is, that's 3 1.3+ that might get fixed with the same patch.

Comment 26

[Jason Smith [:jsmith]]

(In reply to Etienne Segonzac (:etienne) from comment #25)
> Ha, bug 963467 might also have the same root cause. A DOMRequest that won't
> return, the good thing is, that's 3 1.3+ that might get fixed with the same
> patch.

Probably is. There's a whole wave of airplane mode regressions that were seen in triage recently, so I wouldn't surprised if there was a single cause of this at the gecko level.

Comment 28

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

This looks RIL's thing. Can you check it?

Comment 29

[Wilfred Mathanaraj [:WDM]]

PM review: This sounds like edge case but given the number of airplane mode issues seen this could be something we fix as part of the set.

Comment 30

[Ken Chang[:kenkai]]

Edgar, please take this bug.

Comment 31

[Edgar Chen [:edgar]]

Attachment: buri_logcat.txt

I can reproduce the bug with below precondition,
- Precondition and STR: same as comment #19.
- Build Info: same as comment #22.
  Device: Buri v1.3 MOZ RIL
  BuildID: 20131214004003

In fact, DOMRequest will return, but it takes about 35 sec.
Before disabling radio power, gecko will try to disconnect all existed data connection first. In this bug, modem takes time to process/response the RIL request, "REQUEST_DEACTIVATE_DATA_CALL". (gecko trigger the callback of DOMRequset after receiving modem's response)

----------------
02-05 15:32:32.349   145   264 I Gecko   : RIL Worker[0]: Received chrome message {"cid":"0","reason":0,"rilMessageToken":20,"rilMessageType":"deactivateDataCall"}
02-05 15:32:32.349   145   264 I Gecko   : RIL Worker[0]: New outgoing parcel of type 41
02-05 15:32:32.349   145   264 I Gecko   : RIL Worker[0]: Outgoing parcel: 0,0,0,28,41,0,0,0,167,0,0,0,2,0,0,0,1,0,0,0,48,0,0,0,0,0,0,0,0,0,0,0

(Modem takes 35 sec to process/response the REQUEST_DEACTIVATE_DATA_CALL)

02-05 15:33:08.519   145   264 I Gecko   : RIL Worker[0]: Solicited response for request type 41, token 167, error 0
02-05 15:33:08.519   145   264 I Gecko   : RIL Worker[0]: Handling parcel as REQUEST_DEACTIVATE_DATA_CALL
-----------------

Hi Anshul, do you have any idea about what's happened here?
Thank you.

Comment 32

[Ken Chang[:kenkai]]

I wonder if this is a really 1.3+ bug. This use case seems not happen in a real usage. When user want to disconnect voice call, he wouldn't directly turn on flight mode.

Comment 33

[Jason Smith [:jsmith]]

(In reply to Ken Chang[:ken](OOO 1/30 ~ 2/4) from comment #32)
> I wonder if this is a really 1.3+ bug. This use case seems not happen in a
> real usage. When user want to disconnect voice call, he wouldn't directly
> turn on flight mode.

We ended up blocking on this originally btw because we think this would be a cert blocker for a target partner given that airplane mode is one of those features that pretty much always has to work.

Comment 34

[Jason Smith [:jsmith]]

http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=dfae9c83bfbc&tochange=f81e19286279

Comment 35

[Preeti Raghunath(:Preeti)]

Can we please find the regressing patch and do a back out?

Comment 36

[Jason Smith [:jsmith]]

Suspected cause of this regression is bug 949876.

Comment 37

[Edgar Chen [:edgar]]

(In reply to Jason Smith [:jsmith] from comment #36)
> Suspected cause of this regression is bug 949876.

It doesn't look like a regression of bug 949876.
And I also had a try with backing out bug 949876, but I could still repro this bug.
I will try to find out a solution anyway.

Thank you.

Comment 38

[Edgar Chen [:edgar]]

Attachment: Patch, v1

When turning off radio power, drop all active voice calls first.

Comment 39

[Anshul]

(In reply to Edgar Chen [:edgar][:echen] from comment #31)
> Created attachment 8370608 [details]
> buri_logcat.txt
> 
> I can reproduce the bug with below precondition,
> - Precondition and STR: same as comment #19.
> - Build Info: same as comment #22.
>   Device: Buri v1.3 MOZ RIL
>   BuildID: 20131214004003
> 
> In fact, DOMRequest will return, but it takes about 35 sec.
> Before disabling radio power, gecko will try to disconnect all existed data
> connection first. In this bug, modem takes time to process/response the RIL
> request, "REQUEST_DEACTIVATE_DATA_CALL". (gecko trigger the callback of
> DOMRequset after receiving modem's response)
> 
> ----------------
> 02-05 15:32:32.349   145   264 I Gecko   : RIL Worker[0]: Received chrome
> message
> {"cid":"0","reason":0,"rilMessageToken":20,"rilMessageType":
> "deactivateDataCall"}
> 02-05 15:32:32.349   145   264 I Gecko   : RIL Worker[0]: New outgoing
> parcel of type 41
> 02-05 15:32:32.349   145   264 I Gecko   : RIL Worker[0]: Outgoing parcel:
> 0,0,0,28,41,0,0,0,167,0,0,0,2,0,0,0,1,0,0,0,48,0,0,0,0,0,0,0,0,0,0,0
> 
> (Modem takes 35 sec to process/response the REQUEST_DEACTIVATE_DATA_CALL)
> 
> 02-05 15:33:08.519   145   264 I Gecko   : RIL Worker[0]: Solicited response
> for request type 41, token 167, error 0
> 02-05 15:33:08.519   145   264 I Gecko   : RIL Worker[0]: Handling parcel as
> REQUEST_DEACTIVATE_DATA_CALL
> -----------------
> 
> Hi Anshul, do you have any idea about what's happened here?
> Thank you.

This doesn't seem like a QC RIL issue.

Comment 40

[Edgar Chen [:edgar]]

Attachment: Part 1: Drop voice call first when power off radio, v2

Comment 41

[Edgar Chen [:edgar]]

Attachment: Part 2: Marionette tests, v1

Comment 42

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Comment on attachment 8372039 [details] [diff] [review]
Part 1: Drop voice call first when power off radio, v2

Review of attachment 8372039 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/RadioInterfaceLayer.js
@@ +620,5 @@
> +        // In 2G network, modem takes 35+ seconds to process deactivate data
> +        // call request if device has active voice call (please see bug 964974
> +        // for more details). Therefore we should hangup all active voice calls
> +        // first.
> +        radioInterface.workerMessenger.send("hangUpAll");

Considering some DSDS architecture with only one modem, toggling one radio may toggle both. Shouldn't we send "hangUpAll" to all clients before this.request()?

Comment 43

[Edgar Chen [:edgar]]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #42)
> Comment on attachment 8372039 [details] [diff] [review]
> Part 1: Drop voice call first when power off radio, v2
> 
> Review of attachment 8372039 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/system/gonk/RadioInterfaceLayer.js
> @@ +620,5 @@
> > +        // In 2G network, modem takes 35+ seconds to process deactivate data
> > +        // call request if device has active voice call (please see bug 964974
> > +        // for more details). Therefore we should hangup all active voice calls
> > +        // first.
> > +        radioInterface.workerMessenger.send("hangUpAll");
> 
> Considering some DSDS architecture with only one modem, toggling one radio
> may toggle both. Shouldn't we send "hangUpAll" to all clients before
> this.request()?

Hmm, you are right, we should send "hangUpAll" to all clients for that case. I will address in next version. Thank you.

Comment 44

[Edgar Chen [:edgar]]

Attachment: Part 1: Drop voice call first when power off radio, v3

Address review comment #42.

Comment 45

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Comment on attachment 8372153 [details] [diff] [review]
Part 1: Drop voice call first when power off radio, v3

Review of attachment 8372153 [details] [diff] [review]:
-----------------------------------------------------------------

Great! Thank you ~

::: dom/system/gonk/RadioInterfaceLayer.js
@@ +619,5 @@
>  
> +        // In 2G network, modem takes 35+ seconds to process deactivate data
> +        // call request if device has active voice call (please see bug 964974
> +        // for more details). Therefore we should hangup all active voice calls
> +        // first. And consider some DSDS architecture, toggling one radio may

nit: s/consider/considering/

@@ +620,5 @@
> +        // In 2G network, modem takes 35+ seconds to process deactivate data
> +        // call request if device has active voice call (please see bug 964974
> +        // for more details). Therefore we should hangup all active voice calls
> +        // first. And consider some DSDS architecture, toggling one radio may
> +        // toggle both, so send hangUpAll to all clients.

nit:s/so send/so we send/

Comment 46

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Comment on attachment 8372040 [details] [diff] [review]
Part 2: Marionette tests, v1

Review of attachment 8372040 [details] [diff] [review]:
-----------------------------------------------------------------

Looks great. Only some nits. Thank you :)

::: dom/telephony/test/marionette/test_outgoing_answer_radio_off.js
@@ +14,5 @@
> +  connection.onradiostatechange = function() {
> +    let state = connection.radioState;
> +    log("Received 'radiostatechange' event, radioState: " + state);
> +
> +    if (state === desiredRadioState) {

Please add the comment:

// We are waiting for 'desiredRadioState.' Ignore any transient state.

@@ +39,5 @@
> +    log("Received 'onalerting' call event.");
> +    call.onalerting = null;
> +    is(call, event.call);
> +    is(call.state, "alerting");
> +

nit: remove the empty line to have a consistent style with other functions

@@ +63,5 @@
> +
> +  return deferred.promise;
> +}
> +
> +function disableRadioAndWaitCallEvent(call) {

nit: s/disableRadioAndWaitCallEvent/disableRadioAndWaitForCallEvent/

@@ +64,5 @@
> +  return deferred.promise;
> +}
> +
> +function disableRadioAndWaitCallEvent(call) {
> +  log("Disable radio and wait call event.");

nit: s/wait call/wait for call/

@@ +81,5 @@
> +  return deferred.promise;
> +}
> +
> +/**
> + * Test making outgoing call then power off radio.

nit: Make an outgoing call then power off radio.

Comment 47

[Edgar Chen [:edgar]]

Attachment: Part 1: Drop voice call first when power off radio, v4, r=hsinyi

Address review comment #45.

Comment 48

[Edgar Chen [:edgar]]

Attachment: Part 2: Marionette tests, v2, r=hsinyi

Address review comment #46.

Comment 49

[Edgar Chen [:edgar]]

Try server: https://tbpl.mozilla.org/?tree=Try&rev=3c3314a4dcdf

Comment 50

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar][:echen] from comment #49)
> Try server: https://tbpl.mozilla.org/?tree=Try&rev=3c3314a4dcdf
All green!

https://hg.mozilla.org/integration/b2g-inbound/rev/c3d9efad7ff9
https://hg.mozilla.org/integration/b2g-inbound/rev/febd18f5beb8

Comment 51

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/c3d9efad7ff9
https://hg.mozilla.org/mozilla-central/rev/febd18f5beb8

Comment 52

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/c168c5bc2e5e
https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/6dddd36ce6f6