1021424 - MMS messages sent with certain SIM manager configurations don't ever send

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[Valentin Tsatskin [:vt]]

# Build Information

Device: Flame
Gaia      d2cfef555dabab415085e548ed44c48a99be5c32
Gecko     https://hg.mozilla.org/mozilla-central/rev/51b428be6213
BuildID   20140605040202
Version   32.0a1
ro.build.version.incremental=94
ro.build.date=Tue May 20 09:29:20 CST 2014

# Description

When there are multiple SIM cards, in certain SIM Manager configurations, MMS messages don't send.

# Steps to Reproduce

1) Open settings
2) Set outgoing messages to SIM 2
3) Set data to SIM 1
4) Send an MMS message with a picture (should go through SIM 2)
5) Switch data connection dialog should open
6) Press "ok" (nothing happens, probably a different bug)
7) Press "later" instead
8) Try to resend message by pressing exclamation icon
9) "The message could not be sent. Try again?" -> Press OK
10) Switch data connection dialog should open
11) Press okay

# Expected Results

Pressing "ok" for the switch data connection dialog should dismiss the dialog and send the message. The MMS message should send.

# Actual Results

Pressing "ok" for the switch data connection dialog does nothing. The MMS message never actually sends and a spinner is shown.

# Reproduction Frequency

Every time

Comment 1

[Julien Wajsberg [:julienw]]

ok, we probably have a regression here, thanks.

Do you know if there is a meaningful logcat ?

Comment 2

[Julien Wajsberg [:julienw]]

> Pressing "ok" for the switch data connection dialog does nothing.

=> this is the issue IMO.

> The MMS message never actually sends and a spinner is shown.

You don't describe this in the steps; can you precise when the spinner is actually shown?

Comment 3

[Johan Lorenzo [:jlorenzo]]

QA Wanted to see if this issue is reproducible on 1.4.

Comment 4

[Valentin Tsatskin [:vt]]

(In reply to Julien Wajsberg [:julienw] from comment #1)
> ok, we probably have a regression here, thanks.
> 
> Do you know if there is a meaningful logcat ?

I've never used logcat, is it this? https://developer.mozilla.org/en-US/Firefox_OS/Debugging/On-device_console_logging

(In reply to Julien Wajsberg [:julienw] from comment #2)
> > Pressing "ok" for the switch data connection dialog does nothing.
> 
> => this is the issue IMO.
> 
> > The MMS message never actually sends and a spinner is shown.
> 
> You don't describe this in the steps; can you precise when the spinner is
> actually shown?

After pressing okay, the message attempts to send as one would expect with a spinner showing. However, it never actually completes (see following screenshot). After a long indeterminate time the spinner eventually turns into the failed message icon.

Comment 5

[Valentin Tsatskin [:vt]]

Attachment: spinner.png

Note: personal information has been removed with black boxes

Comment 6

[Jason Smith [:jsmith]]

Let's get branch info first.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #6)
> Let's get branch info first.

Can we get reduced STR to see this bug?

Comment 8

[Julien Wajsberg [:julienw]]

(In reply to Valentin Tsatskin [:vt] from comment #4)
> (In reply to Julien Wajsberg [:julienw] from comment #1)
> > ok, we probably have a regression here, thanks.
> > 
> > Do you know if there is a meaningful logcat ?
> 
> I've never used logcat, is it this?
> https://developer.mozilla.org/en-US/Firefox_OS/Debugging/On-
> device_console_logging
> 

Exactly this :)

> 
> After pressing okay, the message attempts to send as one would expect with a
> spinner showing.

So pressing OK, there _is_ actually something happening.
Do you notice that the "data" connection is changed (you can see from the icons in the status bar)?

Comment 9

[Cody Roesch [:croesch]]

This bug does NOT occur on Flame 1.4. When Outgoing messages are set to SIM 2 and a MMS is sent, the message will always send although it can take up to 10-15 seconds.

I made sure that I was able to repro the bug in 2.0 exactly as the reporter stated.

Environmental Variables:
Device: Flame 1.4
Build ID: 20140610000204
Gaia: 57c6a24f7c7d16aac132f3cecd3ff9ee8d53cf78
Gecko: 54a7aa1a0423
Version: 30.0 (1.4) 
Firmware Version: v10G-2

Comment 10

[bhavana bajaj [:bajaj]]

Can we get reduced STR here? The reported steps are valid but is those are the minimum steps to hit the issue, I doubt that's realistic, happy to get corrected here :)

Comment 11

[Julien Wajsberg [:julienw]]

Bhavana: the first issue happens at step 6, and this is likely to happen if the user has the "data" preference set on one SIM and the "sms preference" set on another SIM.

I haven't tried reproducing on my side yet.

Comment 12

[Jason Smith [:jsmith]]

We need the reduced STR before window, so removing the window flag.

Comment 13

[Duane Dixon [:ddixon]]

Reduced STR:

1) Open Settings>SIM Manager
2) Set Outgoing Messages to SIM 2
3) Set Data and Outgoing Calls to SIM 1
4) Send MMS with a picture
5) Press "Later" at switch data dialogue screen
6) Press on failed message (red exclamation point)
7) Press "OK" at  Messages dialogue screen
8) Press "OK"  when data connection dialog opens
9) Observe MMS spinner appears and MMS never sends

Note: Step 5 is necessary because there is another issue that does not allow user to press "Ok" the first time they encounter that paticular dialogue screen. 

Currently finding regression window, if needed.

Comment 14

[Jason Smith [:jsmith]]

9 steps is not reduced STR. Please try getting the reduced STR here again.

Comment 15

[Julien Wajsberg [:julienw]]

Again, to me, the bug is steps 1 to 6 in comment 0. The next steps are noise, or I don't understand what they bring.

Comment 16

[Duane Dixon [:ddixon]]

Prerequisets: Assign Out Going Messages to SIM 2.  Assign Outgoing Calls and Data to SIM 1. 

Reduced STR:
1) Send MMS with a picture.
2) Press "Later" then tap on failed message
3) Press Ok on the next two dialogue screens

Video URL: https://www.youtube.com/watch?v=N7OnyGzBVjc&edit=vd

Comment 17

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

triage: blocker as this is regression and the actual result is bad experience.

Comment 18

[Duane Dixon [:ddixon]]

The initial regression window for this bug pointed towards both the Mozilla Inbound and B2G Inbound branches.  

I feel that the Gecko Pushlog for the B2G Inbound window has a good candidate for the cause of this bug.  Specifically, Bug 939046 seems to be a patch dealing with data handling.  

I can also provide the regression window for the Mozilla Inbound branch if needed. 

B2G Inbound Regression Window

Last Working 

Device: Flame 
Build ID: 20140527023021
Gaia: e6dd9744778e26241bd65dda51f3db43ec9e40c4
Gecko: 5b2a6a5af87a
Version: 32.0a1 (Master)
Firmware Version: v121-2

First Broken

Device: Flame 
Build ID: 20140527053007
Gaia: 9c7e0ace045074c08b96b198aaf6c5d39ce302dd
Gecko: 3ebd3510cb7c
Version: 32.0a1 (Master)
Firmware Version: v121-2

Last Working Gaia and First Broken Gecko
Issue DOES occur here. 
Gaia: e6dd9744778e26241bd65dda51f3db43ec9e40c4
Gecko: 3ebd3510cb7c

Last Working Gecko and First Broken Gaia
Issue DOES NOT occur here. 
Gaia: 9c7e0ace045074c08b96b198aaf6c5d39ce302dd
Gecko: 5b2a6a5af87a


Gecko Pushlog: 
http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=5b2a6a5af87a&tochange=3ebd3510cb7c

Comment 19

[Jason Smith [:jsmith]]

Jessica - Can you take a look? As the above comment suggests, bug 939046 is suspected for causing this regression.

Comment 20

[Jessica Jong [:jessica] (inactive)]

(In reply to Jason Smith [:jsmith] from comment #19)
> Jessica - Can you take a look? As the above comment suggests, bug 939046 is
> suspected for causing this regression.

Sure, I will take a look and get back to you soon. Keeping the ni flag for tracking.

Comment 21

[Jessica Jong [:jessica] (inactive)]

I was able to reproduce this by letting SIM2's data and mms share the same APN.

The root cause is because on 'network-connection-state-changed', MmsService will set mms apn settings if |getDataCallStateByType("mms")| returns true, regardless of the received network.type [1]. This was kind of a workaround cause network.type/network.state was not reliable.

After bug 939046, the network.type on 'network-connection-state-changed' is set correctly, so we should verify if the network.type received is 'mms' first.

I'll provide a patch to fix this.

[1] https://hg.mozilla.org/integration/b2g-inbound/file/3a9209d7df39/dom/mobilemessage/src/gonk/MmsService.js#l468   (-l499)

Comment 22

[Jessica Jong [:jessica] (inactive)]

Attachment: patch, v1.

Bevis, the 'network-connection-state-changed' part I think is more straightforward, could you check if the 'init' part is doing what it is expected? Thanks.

Comment 23

[Bevis Tseng[:bevis][:btseng](Exited)]

Comment on attachment 8445018 [details] [diff] [review]
patch, v1.

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

::: dom/mobilemessage/src/gonk/MmsService.js
@@ +304,5 @@
>        // Set up the MMS APN setting based on the connected MMS network,
>        // which is going to be used for the HTTP requests later.
>        this.setApnSetting(rilNetwork);
>      }
>    },

As discussed offline, we could simplify the init() as followed:
  init: function() {
    Services.obs.addObserver(this, kNetworkConnStateChangedTopic,
                             false);
    Services.obs.addObserver(this, NS_XPCOM_SHUTDOWN_OBSERVER_ID, false);
  }

The reasons are that
1. In new NetworkManager design, networkInterface of selected type will only be connected after requested even it belongs to a shared APN.
2. In MmsService, each MmsConnection object is lazily-created after a sending/retrievel is requested and then persistently exists to represent a handle of the MMS connection per RadioInterface.
3. In this case, the scenario of having MMS networkInterface connected before MmsConnection.init() looks not possible anymore.

Comment 24

[Jessica Jong [:jessica] (inactive)]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #23)
> Comment on attachment 8445018 [details] [diff] [review]
> patch, v1.
> 
> Review of attachment 8445018 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/mobilemessage/src/gonk/MmsService.js
> @@ +304,5 @@
> >        // Set up the MMS APN setting based on the connected MMS network,
> >        // which is going to be used for the HTTP requests later.
> >        this.setApnSetting(rilNetwork);
> >      }
> >    },
> 
> As discussed offline, we could simplify the init() as followed:
>   init: function() {
>     Services.obs.addObserver(this, kNetworkConnStateChangedTopic,
>                              false);
>     Services.obs.addObserver(this, NS_XPCOM_SHUTDOWN_OBSERVER_ID, false);
>   }
> 
> The reasons are that
> 1. In new NetworkManager design, networkInterface of selected type will only
> be connected after requested even it belongs to a shared APN.
> 2. In MmsService, each MmsConnection object is lazily-created after a
> sending/retrievel is requested and then persistently exists to represent a
> handle of the MMS connection per RadioInterface.
> 3. In this case, the scenario of having MMS networkInterface connected
> before MmsConnection.init() looks not possible anymore.

Thanks for the feedback, will upload a new patch to address this.

Comment 25

[Jessica Jong [:jessica] (inactive)]

Attachment: patch, v2.

Hi Vicamo, this is to fix the following exception: 

I/Gecko   (  317): -*- RILNetworkInterface[1:1]: Error! Only MMS network can get MMSC.
E/GeckoConsole(  317): [JavaScript Error: "NS_ERROR_UNEXPECTED: Unexpected error'Unexpected error' when calling method: [nsIRilNetworkInterface::mmsc]" {file: "jar:file:///system/b2g/omni.ja!/components/MmsService.js" line: 218}]

Please refer to the details in comment 21.
May I have your review? Thanks.

Comment 26

[Vicamo Yang [:vicamo][:vyang]]

Comment on attachment 8445043 [details] [diff] [review]
patch, v2.

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

Thank you.

::: dom/mobilemessage/src/gonk/MmsService.js
@@ -284,5 @@
>                               false);
>      Services.obs.addObserver(this, NS_XPCOM_SHUTDOWN_OBSERVER_ID, false);
> -
> -    this.connected = this.radioInterface.getDataCallStateByType("mms") ==
> -      Ci.nsINetworkInterface.NETWORK_STATE_CONNECTED;

Then it implies a mms data connection must only be connected by MmsService's request. Anyway, we should integrate this into NetworkManager as soon as possible.

Comment 27

[Jessica Jong [:jessica] (inactive)]

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #26)
> Comment on attachment 8445043 [details] [diff] [review]
> patch, v2.
> 
> Review of attachment 8445043 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Thank you.
> 
> ::: dom/mobilemessage/src/gonk/MmsService.js
> @@ -284,5 @@
> >                               false);
> >      Services.obs.addObserver(this, NS_XPCOM_SHUTDOWN_OBSERVER_ID, false);
> > -
> > -    this.connected = this.radioInterface.getDataCallStateByType("mms") ==
> > -      Ci.nsINetworkInterface.NETWORK_STATE_CONNECTED;
> 
> Then it implies a mms data connection must only be connected by MmsService's
> request. Anyway, we should integrate this into NetworkManager as soon as
> possible.

Totally agree! Thanks for the review.

Comment 28

[Jessica Jong [:jessica] (inactive)]

try green: https://tbpl.mozilla.org/?tree=Try&rev=dce587399058

Comment 29

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/b2g-inbound/rev/3b6149f227d6

Comment 30

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3b6149f227d6

Comment 31

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/a2df04e4f4d8

Comment 32

[Lancy(Leave from Mozilla)]

Attachment: Verify_Video_Flame.MP4

This issue has been verified successfully on Flame 2.0 & 2.1.
See attachment: Verify_Video_Flame.MP4
Reproducing rate: 0/5

Flame v2.0 version:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/29222e215db8
Build-ID        20141203000201
Version         32.0

Flame v2.1 version:
Gaia-Rev        dbaf3e31c9ba9c3436e074381744f2971e15c7bf
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ebce587d2194
Build-ID        20141203001205
Version         34.0