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

RESOLVED FIXED in Firefox 32, Firefox OS v2.0

Status

Firefox OS
RIL
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: vt, Assigned: jessica)

Tracking

({regression})

unspecified
2.0 S5 (4july)
ARM
Gonk (Firefox OS)
regression
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.0+, firefox31 wontfix, firefox32 fixed, firefox33 fixed, b2g-v1.4 unaffected, b2g-v2.0 verified, b2g-v2.1 verified)

Details

(Whiteboard: [2.0-FL-bug-bash][p=1], URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

4 years ago
# 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
(Reporter)

Updated

4 years ago
blocking-b2g: --- → 2.0?
ok, we probably have a regression here, thanks.

Do you know if there is a meaningful logcat ?
Keywords: regression, regressionwindow-wanted
> 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?
Flags: needinfo?(vtsatskin)
QA Wanted to see if this issue is reproducible on 1.4.
User Story: (updated)
Keywords: qawanted
(Reporter)

Comment 4

4 years ago
(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.
(Reporter)

Comment 5

4 years ago
Created attachment 8435945 [details]
spinner.png

Note: personal information has been removed with black boxes
Flags: needinfo?(vtsatskin)

Updated

4 years ago
Keywords: regressionwindow-wanted
Let's get branch info first.
(In reply to Jason Smith [:jsmith] from comment #6)
> Let's get branch info first.

Can we get reduced STR to see this bug?
(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)?
Flags: needinfo?(vtsatskin)
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
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v1.4: --- → unaffected
Flags: needinfo?(jmitchell)
Keywords: qawanted → regressionwindow-wanted
QA Contact: croesch
Flags: needinfo?(jmitchell)
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 :)
Keywords: qawanted
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.

Updated

4 years ago
QA Contact: croesch → ddixon
We need the reduced STR before window, so removing the window flag.
Keywords: regressionwindow-wanted
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.
Flags: needinfo?(jmitchell)
Flags: needinfo?(jmitchell)
Keywords: qawanted → regressionwindow-wanted
9 steps is not reduced STR. Please try getting the reduced STR here again.
Keywords: regressionwindow-wanted → qawanted
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.
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
Flags: needinfo?(jmitchell)
triage: blocker as this is regression and the actual result is bad experience.
blocking-b2g: 2.0? → 2.0+
Flags: needinfo?(jmitchell)
Keywords: qawanted → regressionwindow-wanted

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage?]
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
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
Jessica - Can you take a look? As the above comment suggests, bug 939046 is suspected for causing this regression.
Blocks: 939046
Component: Gaia::SMS → RIL
Flags: needinfo?(jjong)

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
(Assignee)

Comment 20

4 years ago
(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.
(Assignee)

Comment 21

4 years ago
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)
Flags: needinfo?(jjong)
(Assignee)

Comment 22

4 years ago
Created attachment 8445018 [details] [diff] [review]
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.
Attachment #8445018 - Flags: feedback?(btseng)
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.
Attachment #8445018 - Flags: feedback?(btseng)
(Assignee)

Comment 24

4 years ago
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) 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.
(Assignee)

Comment 25

4 years ago
Created attachment 8445043 [details] [diff] [review]
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.
Attachment #8445018 - Attachment is obsolete: true
Attachment #8445043 - Flags: review?(vyang)
Attachment #8445043 - Flags: feedback?(btseng)
Attachment #8445043 - Flags: feedback?(btseng) → feedback+
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.
Attachment #8445043 - Flags: review?(vyang) → review+
(Assignee)

Comment 27

4 years ago
(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.
(Assignee)

Comment 28

4 years ago
try green: https://tbpl.mozilla.org/?tree=Try&rev=dce587399058
Keywords: checkin-needed
(Assignee)

Updated

4 years ago
Assignee: nobody → jjong
Whiteboard: [2.0-FL-bug-bash] → [2.0-FL-bug-bash][p=1]
Target Milestone: --- → 2.0 S5 (4july)
https://hg.mozilla.org/mozilla-central/rev/3b6149f227d6
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
https://hg.mozilla.org/releases/mozilla-aurora/rev/a2df04e4f4d8
status-b2g-v2.0: --- → fixed
status-b2g-v2.1: --- → fixed
status-firefox31: --- → wontfix
status-firefox32: --- → fixed
status-firefox33: --- → fixed
(Reporter)

Updated

4 years ago
Flags: needinfo?(vtsatskin)

Updated

4 years ago
Depends on: 1053551
Created attachment 8531908 [details]
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
status-b2g-v2.0: fixed → verified
status-b2g-v2.1: fixed → verified
You need to log in before you can comment on or make changes to this bug.