884829 - [MMS] Impossible to send/receive MMS when Wi-Fi and cellular data on

Status: VERIFIED FIXED

(Core :: DOM: Device Interfaces, defect)

Description

[Noemí Freire (:noemi)]

PROCEDURE
Cellular data is on
Wi-Fi is connected to any network
Scenario 1. On unagi device, send a MMS to another device
Scenario 2. From another device send an MMS to unagi device


Scenario 1 (sending a MMS):
Currently -> It is not possible to successfully send a MMS, when clicking on send button spinner icon is shown, and finally, failure icon appears after a while
Expected -> MMS should be properly sent


Scenario 2 (receiving a MMS):
a. In case auto-retrieve on:
Currently -> a notification arrives and the download process is automatically initiated, spinner icon is indefinitely shown
Expected -> MMS should be properly received, no notification at all

b. In case auto-retrieve off:
Currently -> a notification arrives, when clicking on download button, the process seems to be initiated but spinner icon is indefinitely shown
Expected -> a notification arrives, when clicking on download the MMS is properly received


Seen on Unagi device with today's (06/19) v1-train build:
Gecko: 856e202
Gaia: aea6834

Comment 1

[Beatriz Rodríguez [:brg]]

This is a certification blocker, please fix it.

Comment 2

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Can not reproduce in CHT, FarEasTone, TaiwanMobile SIM cards. Those are the operators in Taiwan. 
Could you please follow below steps to get log with MMS log for me? Those informations will be very useful for me because of I have no vodafone SIM card. Please use adb logcat -v time -b main -b radio. Thanks.

rm user.js 2>/dev/null
adb remount
adb pull /system/b2g/defaults/pref/user.js user.js
sed -i -e '$ a\
pref("ril.debugging.enabled", true);\
pref("mms.debugging.enabled", true);
' user.js
adb push user.js /system/b2g/defaults/pref/user.js
adb shell reboot

## update for replacing user.js script

Comment 3

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

After talk with Ken and do more tests, looks like bug 837488 might be able fix this issue.

Comment 4

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

By the way, are you use QC RIL? If yes, this bug might also need QC's effort.

Comment 5

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Anshul, Could you please find a shared APN sim card to do the test too?

Comment 6

[Noemí Freire (:noemi)]

Attachment: Sending MMS when Wi-Fi and cellular data on

Comment 7

[Noemí Freire (:noemi)]

Attachment: Receiving MMS when Wi-Fi and cellular data On (auto-retrieve On)

Comment 8

[Noemí Freire (:noemi)]

(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #4)
> By the way, are you use QC RIL? If yes, this bug might also need QC's effort.

I'm using Mozilla RIL

Comment 9

[Anshul]

Phil will take a look.

Comment 10

[pgravel]

This will require a change in QC RIL. I am working on a patch.

Comment 11

[Ken Chang[:kenkai]]

Attachment: WIP V1

Comment 12

[Ken Chang[:kenkai]]

Attachment: WIP V1.1

Comment 13

[Ken Chang[:kenkai]]

Attachment: V1.1

Comment 14

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

Comment on attachment 768229 [details] [diff] [review]
V1.1

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

Overall it looks good. Once some functions are renamed as comments below, I think this patch shall be ready.

::: dom/system/gonk/RadioInterfaceLayer.js
@@ +2734,5 @@
>        return false;
>      }
>    },
>  
> +  sharedApnSetupDataCall: function sharedApnSetupDataCall(apntype) {

Rename it to setupDataCallBySharedApn().

@@ +2753,5 @@
> +      }
> +
> +      // Notify the network manager that the interface status has been changed.
> +      // Then the network manage will get the interface status again and know
> +      // the new type of this interface.

I think this short description below should be enough.

// Update the interface status via-registration if the interface has already been registered in the network manager.

@@ +2755,5 @@
> +      // Notify the network manager that the interface status has been changed.
> +      // Then the network manage will get the interface status again and know
> +      // the new type of this interface.
> +      if (this.dataNetworkInterface.name in gNetworkManager.networkInterfaces) {
> +        gNetworkManager.unregisterNetworkInterface(this.dataNetworkInterface);

nit: indention

@@ +2757,5 @@
> +      // the new type of this interface.
> +      if (this.dataNetworkInterface.name in gNetworkManager.networkInterfaces) {
> +        gNetworkManager.unregisterNetworkInterface(this.dataNetworkInterface);
> +      }
> +      gNetworkManager.registerNetworkInterface(this.dataNetworkInterface);

nit: Add an extra line here.

@@ +2767,3 @@
>  
>    setupDataCallByType: function setupDataCallByType(apntype) {
> +    // If it's a shared apn type and we can only reuse the dataNetworkInterface

nit:/and we/then we

@@ +2789,5 @@
>          break;
>      }
>    },
>  
> +  sharedApnDeactivateDataCall: function sharedApnDeactivateDataCall(apntype) {

Rename it to DeactivateDataCallBySharedApn().

@@ +2804,5 @@
> +      let dataInfo = this.rilContext.data;
> +      if (apntype == "default" && dataInfo.connected) {
> +        dataInfo.connected = false;
> +        this._sendMobileConnectionMessage("RIL:DataInfoChanged", dataInfo);
> +      }

nit: Add an extra line here.

@@ +2807,5 @@
> +        this._sendMobileConnectionMessage("RIL:DataInfoChanged", dataInfo);
> +      }
> +      // Notify the network manager that the interface status has been changed.
> +      // Then the network manage will get the interface status again and know
> +      // the new type of this interface.

I think this short description below should be enough.

// Update the interface status via re-registration if the interface has already been registered in the network manager.

@@ +2811,5 @@
> +      // the new type of this interface.
> +      if (this.dataNetworkInterface.name in gNetworkManager.networkInterfaces) {
> +        gNetworkManager.unregisterNetworkInterface(this.dataNetworkInterface);
> +      }
> +      gNetworkManager.registerNetworkInterface(this.dataNetworkInterface);

nit: add an extra line here.

@@ +2822,2 @@
>    deactivateDataCallByType: function deactivateDataCallByType(apntype) {
> +    // If it's a shared apn type and we can only reuse the dataNetworkInterface

nit: s/and we/then we

@@ +2844,5 @@
>      }
>    },
>  
>    getDataCallStateByType: function getDataCallStateByType(apntype) {
> +    // If it's a shared apn type and we can only reuse the dataNetworkInterface

nit: s/and we/then we

Comment 15

[Ken Chang[:kenkai]]

Attachment: WIP V1.2

Comment 16

[Ken Chang[:kenkai]]

Comment on attachment 768252 [details] [diff] [review]
WIP V1.2

I have modified patch according to what you suggested.

Comment 17

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

Comment on attachment 768252 [details] [diff] [review]
WIP V1.2

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

Looks great! Thank you.

Comment 18

[Ken Chang[:kenkai]]

Attachment: WIP V1.3

Comment 19

[Ken Chang[:kenkai]]

Attachment: Support shared APN for MMS, Patch V1.3, r=hsinyi

Comment 20

[Ken Chang[:kenkai]]

Attachment: [b2g18]Support shared APN for MMS, Patch V1.3, r=hsinySi

Comment 21

[Ken Chang[:kenkai]]

Attachment: [b2g18]Support shared APN for MMS, Patch V1.3, r=hsinyi

Comment 22

[Ken Chang[:kenkai]]

Comment on attachment 768737 [details] [diff] [review]
[b2g18]Support shared APN for MMS, Patch V1.3,  r=hsinyi

This patch is for b2g18.

Comment 23

[Ken Chang[:kenkai]]

Comment on attachment 768734 [details] [diff] [review]
Support shared APN for MMS, Patch V1.3,  r=hsinyi

This patch is for m-c

Comment 24

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

http://hg.mozilla.org/projects/birch/rev/d6d9b6f66194

Comment 25

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

Comment on attachment 768737 [details] [diff] [review]
[b2g18]Support shared APN for MMS, Patch V1.3,  r=hsinyi

You don't need to set check-in? for b2g18 patch in this case. It will follow a normal uplift process once m-c patch is landed.

Comment 26

[Ken Chang[:kenkai]]

Attachment: Add === back

Comment 27

[Ken Chang[:kenkai]]

Attachment: [b2g18]Support shared APN for MMS, Patch V1.3, r=hsinyi

Comment 28

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

http://hg.mozilla.org/projects/birch/rev/d6d9b6f66194
http://hg.mozilla.org/projects/birch/rev/424ae3dbaebf

Comment 29

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/d6d9b6f66194
https://hg.mozilla.org/mozilla-central/rev/424ae3dbaebf

Comment 30

[isabelrios]

Hi, 
With 01/07 unagi v1-train build:
Gecko-f9597b
Gaia-c7472ac
Using a movistar spain sim card:

Scenario 1 is verified: 
-Scenario 1 (sending a MMS):
Expected -> MMS should be properly sent

But scenarios 2a and 2b are still failing: 
-Scenario 2 (receiving a MMS):
--a. In case auto-retrieve on:
Currently -> There is not any notification but the MMS appears in inbox. The download process is automatically initiated, spinner icon is indefinitely shown
Expected -> MMS should be properly received

--b. In case auto-retrieve off:
Currently -> a notification arrives, when clicking on download button, the process seems to be initiated but spinner icon is indefinitely shown
Expected -> a notification arrives, when clicking on download the MMS is properly received

Should I re-open this bug or create a new one to follow up the two scenarios described above?

Thanks

Comment 31

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/8fd1c8de4e3a

Comment 32

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/8fd1c8de4e3a

Comment 34

[Ken Chang[:kenkai]]

(In reply to Isabel Rios [:isabel_rios] from comment #30)
This bug isn't able to be reproduced in 03/07 unagi v1-train build. 
Can you verify it again? By the way, did you use the build with moz ril for this test?

Comment 35

[isabelrios]

(In reply to Ken Chang from comment #34)
> (In reply to Isabel Rios [:isabel_rios] from comment #30)
> This bug isn't able to be reproduced in 03/07 unagi v1-train build. 
> Can you verify it again? By the way, did you use the build with moz ril for
> this test?

Hi Ken,

With today (07/03) unagi v1-train build
Gecko-109f9e3
Gaia-2c40cce

There is still one case failing, case b:

--b. In case auto-retrieve off:
Currently -> the message is downloaded automatically as if the auto-retrieve option was set to on. 

Expected -> a notification arrives, when clicking on download the MMS is properly received

If this is ok for you, I will open a new bug to follow this up as the other points why this bug was created in the beginning are already fixed.

Comment 36

[Ken Chang[:kenkai]]

(In reply to Isabel Rios [:isabel_rios] from comment #35)
> 
> --b. In case auto-retrieve off:
> Currently -> the message is downloaded automatically as if the auto-retrieve
> option was set to on. 
> 
> Expected -> a notification arrives, when clicking on download the MMS is
> properly received
> 
> If this is ok for you, I will open a new bug to follow this up as the other
> points why this bug was created in the beginning are already fixed.
This is another issue, please create another bug for this issue.

Comment 37

[isabelrios]

Verified with unagi device 07/07 build:
Gecko-e7708d4
Gaia-d336288

Case in comment 36 is also working fine.