1169187 - [MMS][B2G] Failed to encode the picture message into MMS PDU with specific CU SIM.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[SandKing]

Attachment: Bug log: logcat_1435.txt

[1.Description]:
[Nexus 5 v2.2&v3.0][Flame v3.0][Message]When a failed MMS was being resent, delete it and then open this conversation again, the deleted MMS will appear again.
Found Time:14:35
See log:"logcat_1435.txt"
See video:"1435.3gp"

[2.Testing Steps]: 
Premise: There is a conversation with a SMS and another failed MMS in device.
1. Launch Message.
2. Choose the conversation 
3. Try to resend the failed MMS.
4. When MMS is being resent, delete the MMS.
5. Back to message list view.
6. Open the conversation again.

[3.Expected Result]: 
6. The unsent MMS you deleted in Step 3 should disappear.

[4.Actual Result]: 
6. The unsent MMS you deleted in Step 3 will display in the conversation again.

[5.Reproduction build]: 
N5 v2.2 build(Affected):
Build ID               20150527002504
Gaia Revision          8084264c4d1e28bc33220bc7443c7425bb76dbcc
Gaia Date              2015-05-27 03:47:15
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/19fcc06fb7ab
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150527.034352
Firmware Date          Wed May 27 03:44:07 EDT 2015
Bootloader             HHZ12f

N5_3.0(Affected):
Build ID               20150527160204
Gaia Revision          05380df3158fa39e1dde1687c0bf11a71f8c6868
Gaia Date              2015-05-27 06:27:27
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/2c815cc65cc9
Gecko Version          41.0a1
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150527.193206
Firmware Date          Wed May 27 19:32:20 EDT 2015
Bootloader             HHZ12f

Flame 2.2(Unaffected) :
Build ID               20150527002504
Gaia Revision          8084264c4d1e28bc33220bc7443c7425bb76dbcc
Gaia Date              2015-05-27 03:47:15
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/19fcc06fb7ab
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150527.040521
Firmware Date          Wed May 27 04:05:32 EDT 2015
Bootloader             L1TC000118D0

Flame 3.0(Affected):
Build ID               20150527160204
Gaia Revision          05380df3158fa39e1dde1687c0bf11a71f8c6868
Gaia Date              2015-05-27 06:27:27
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/2c815cc65cc9
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150527.193645
Firmware Date          Wed May 27 19:36:54 EDT 2015
Bootloader             L1TC000118D0

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]: 
Free Test

[8. Note]:
I tried more than 10 times on Flame 2.2, But I can not repro this bug on it

Comment 1

[SandKing]

Attachment: Bug video: 1435.3GP

Comment 2

[Julien Wajsberg [:julienw]]

I see an error in the log:

05-28 14:35:48.869 W/GeckoConsole(  195): [JavaScript Error: "TypeError: this.istream is null" {file: "jar:file:///system/b2g/omni.ja!/components/MmsService.js" line: 1320}]

Bevis maybe this bug is more for you ?

Comment 3

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

(In reply to Julien Wajsberg [:julienw] from comment #2)
> I see an error in the log:
> 
> 05-28 14:35:48.869 W/GeckoConsole(  195): [JavaScript Error: "TypeError:
> this.istream is null" {file:
> "jar:file:///system/b2g/omni.ja!/components/MmsService.js" line: 1320}]
> 
> Bevis maybe this bug is more for you ?

The error cause looks not related to this bug.
line: 1320 shows that there is something wrong when trying to encode a outgoing MMS message into a PDU stream for sending:
http://mxr.mozilla.org/mozilla-b2g37_v2_2/source/dom/mobilemessage/gonk/MmsService.js#1320

However, there seems no debug messages enabled in the attached log.

Hi SandKing,

Can you help to collect more logs with the instruction below:
https://github.com/bevis-tseng/Debug_Tools

Thanks!

Comment 4

[SandKing]

Attachment: Radio log: logcat_radio_1118.txt

Hi Bevis,
These are the logs you need. But now there is something wrong which causes that I can't fetch the tcpdump. So the tcpdump has not been attached yet. If there is anything else you want, please feel free to contact.
See main logcat"logcat_1122.txt"
See radio logcat"logcat_radio_1118.txt"

Comment 5

[SandKing]

Attachment: Main log: logcat_1122.txt

Comment 6

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

(In reply to SandKing from comment #5)
> Created attachment 8612715 [details]
> Main log: logcat_1122.txt

Hi SandKing,

Thanks for collecting the logs.
After investigating the log, I can't not find other error except the one we have seen in comment 2.

I am wondering if that's the problem that cause the deletion mal-function.
Unfortunately, I can not reproduce this problem by my flame-kk with gecko from mozilla-central.

Would you mind to provide more input about:
1. How did you make the MMS message failed?
   (That could be the reason why we saw the error dump in comment 2 and in the log from comment 5.
2. Is the outgoing MMS message failed when attached with this specific picture?
3. Is the deletion operation only failed with this failed MMS message?
4. Is it possible to have more precise STR, then I can reproduce/debug this problem locally?

For questions 2) and 3), if yes, would you mind to provide the test picture for further analysis?

In addition, if this can not be reproduced in our side, I am not pretty sure if you are able to have gecko built locally. If yes, is it possible to enable one more log manually by changing the debug flags in MobileMessageDB.jsm and then capture the main log again with mms/ril logs enabled? [1]

Thanks!

[1] https://dxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/MobileMessageDB.jsm#25

Comment 7

[SandKing]

Hi Bevis,
For the 1 question: No matter what method you use, it’s ok. (I sent the MMS to an invalid recipient, and also a valid one and then I removed the SIM to realize the MMS failure.)

For 2&3: It is not the specific picture or MMS when it fails.

Now I would like to provide you with more detailed steps:
1. Send a SMS to a valid number (This can prevent that when MMS is deleted, the conversation will also disappear.)
2. Send a MMS to this number (Any picture can do). Before MMS has been sent successfully, remove the SIM, and reboot device.
3. After reboot, open the conversation and resend the failed MMS.
4. When device is resending this MMS, delete it.
5. Back to message list view, and then reopen this conversation. You can find the deleted MMS is displayed in the conversation.
Note: According to comment6, I find you are using Flame to reproduce. But please note this bug does not exist on Flame 2.2.

Comment 8

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

(In reply to SandKing from comment #7)
> Note: According to comment6, I find you are using Flame to reproduce. But
> please note this bug does not exist on Flame 2.2.

Thanks for reminding. That's why I reproduced this with mozilla-central build (v3).

Comment 9

[SandKing]

Hi Bevis,
This issue can be reproduced sucessfully when I insert CU SIM card, but fails when I insert the CMCC SIM card., it might be the most important step

Comment 10

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

(In reply to SandKing from comment #9)
> Hi Bevis,
> This issue can be reproduced sucessfully when I insert CU SIM card, but
> fails when I insert the CMCC SIM card., it might be the most important step

This sounds quite weird to me because, in the STR, the storage operation shall not be related to the connected network. :(

I'd to provide a patch which enables more logs for further investigation.

Comment 11

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

Attachment: Enable MMS related DEBUG flags.

Hi SandKing,

Since this problem can only be reproduced in your side for now,
would you please help to have a gecko build locally with this patch applied and then capture the main log for further investigation?

Thanks!

Comment 12

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

(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #11)
> Created attachment 8612788 [details] [diff] [review]
> Enable MMS related DEBUG flags.
> 
> Hi SandKing,
> 
> Since this problem can only be reproduced in your side for now,
> would you please help to have a gecko build locally with this patch applied
> and then capture the main log for further investigation?
> 
> Thanks!

BTW, please ensure the STRs in comment 7 are all captured and point out the timestamp when the symptom happens.
(Note: adb will be disconnected when device reboot, you'll have to capture the log again after device rebooting)

Comment 13

[SandKing]

Attachment: Main log: logcat_1351.txt

Hi Bevis,
I have used the patch in comment 11 to build a new ROM, and reproduced this bug. The log you requied is attached. If you need any other help, please contact me directly.
See main log:"logcat_1351.txt"
See radio logcat"logcat_radio_1351.txt"

Comment 14

[SandKing]

Attachment: Radio log: logcat_radio_1351.txt

Flame 3.0 build:
Build ID               20150601104435
Gaia Revision          4ac2e0e4f7ef9c863143a4d6da21afdeb8ab8940
Gaia Date              2015-05-30 12:49:36
Gecko Revision         n/a
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.rose.20150601.102540
Firmware Date          2015年 06月 01日 星期一 10:26:03 CST
Bootloader             L1TC000118D0

Comment 15

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

(In reply to SandKing from comment #13)
> Created attachment 8613387 [details]
> Main log: logcat_1351.txt
> 
> Hi Bevis,
> I have used the patch in comment 11 to build a new ROM, and reproduced this
> bug. The log you requied is attached. If you need any other help, please
> contact me directly.
> See main log:"logcat_1351.txt"
> See radio logcat"logcat_radio_1351.txt"

Hi SandKing,

Thanks for capturing the logs.
From the log, there is always one error as what has been seen in comment 2 that the MMS message cannot be encoded properly when sending.

Hence, I'd like to know 
1. Can the picture be sent successfully if you don't reboot the device when sending.
2. Can you help to capture 2 main logs:
   1. the log that contains step1~step2 in comment 7. (This seems not included in previous attachment)
   2. the log that contains step3~step5 in comment 7.
3. Is this still reproducible with CU SIM only? :(
4. Can you help to attach the picture you test for us to try see we can reproduce it locally?

Thanks!

Comment 16

[SandKing]

Attachment: Before restart log: logcat_1355.txt

Hi Bevis,
We've no idea what has happened. Now we have only one CU card which can reproduce this bug(there were another 2 CU cards which can do, but now we fail to reproduce with them), but now this only CU card fails to send MMS( I'm sure that this card used to send successfully). I've fetched the log you want. If there is anything else you need, please feel free to contact me.
See before restart log: "logcat_1355.txt".
See after restart log:"logcat_1358.txt".
See attachment picture:"0b4ef039b6003af34d276da4352ac65c1238b6f6.jpg"

Comment 17

[SandKing]

Attachment: After restart log: logcat1358.txt

Comment 18

[SandKing]

Attachment: Attachment picture: 0b4ef039b6003af34d276da4352ac65c1238b6f6.jpg

Comment 19

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

(In reply to SandKing from comment #16)
> Created attachment 8614520 [details]
> Before restart log: logcat_1355.txt
> 
> Hi Bevis,
> We've no idea what has happened. Now we have only one CU card which can
> reproduce this bug(there were another 2 CU cards which can do, but now we
> fail to reproduce with them), but now this only CU card fails to send MMS(
> I'm sure that this card used to send successfully). I've fetched the log you
> want. If there is anything else you need, please feel free to contact me.
> See before restart log: "logcat_1355.txt".
> See after restart log:"logcat_1358.txt".
> See attachment picture:"0b4ef039b6003af34d276da4352ac65c1238b6f6.jpg"

Hi SandKing,

Thanks for confirming the symptom.
It sounds reasonable to me compared to the log I have investigated.
Due to the exception in comment 2, this prevents MmsService to report the error to gaia to delete the pending message.

Actually, when resending a message, 
1. sms app will clone the Message and request to send this clone message.
2. after message is sent or message is failed to sent, sms app will delete the original one.

However, when the error in comment 2 happens, there is no further response back to the caller.
Hence, when user deletes the message to be sent, the original one mentioned in 2) will still be there.
That's why we saw there is a failed message after re-entering the thread view.

Hence, the root cause is why gecko cannot encode this MMS into a PDU properly.
I've try to reproduce this with the attached picture.
Unfortunately, this picture can be sent properly by my flame.

I'll try to add more log and ask for your help to collect the logcat again for further analysis.

Change the bug title properly according to what we have found so far.

Comment 20

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

Hi SandKing,

After checking the log, I found a suspicious point that could be the root cause of this bug.
In the log, the from address in MMS header looks abnormal:
"from":{"address":"undefined","type":"PLMN"},
In normal case, if the msisdn is not available, we shall see the following printed instead:
"from": null

After I hard-code this to the phone number to "undefined" in [1],
I can see the same error locally. Hence, we are more closer to the root cause now. :)

However, there is no logcat start from the beginning to see why the msisdn from the inserted SIM card will be interpreted as "undefined".

Hence, I need your help again to capture both main & radio log from the beginning with the same debug flags applied to see what happened.
1. Shutdown the device.
2. adb logcat -v threadtime -b main > main_log.txt
3. adb logcat -v threadtime -b radio > main_log.txt
4. Bootup the device.

Thanks!

[1] https://dxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/MmsService.js#1220

Comment 21

[SandKing]

Attachment: Radio log: radio_log.txt

Hi Bevis,
Here is the log you need. But you've said that SIM card will be interpreted as "undefined". I guess this may happen when you are required to input PIN after starting up. But when I was resending, SIM was indeed in recognized status. So "undefined" behaviour should not occour. But that is just my guess. If you need any help, please feel free to contact me.
See main log:"main_log.txt".
See radio log:"main_log.txt"

Comment 22

[SandKing]

Attachment: Main log: main_log.txt

Comment 23

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

(In reply to SandKing from comment #21)
> Created attachment 8615053 [details]
> Radio log: radio_log.txt
> 
> Hi Bevis,
> Here is the log you need. But you've said that SIM card will be interpreted
> as "undefined". I guess this may happen when you are required to input PIN
> after starting up. But when I was resending, SIM was indeed in recognized
> status. So "undefined" behaviour should not occour. But that is just my
> guess. If you need any help, please feel free to contact me.
> See main log:"main_log.txt".
> See radio log:"main_log.txt"

Hi SandKing,

What I'd like to point out is not about SIM detection but about the MSISDN field inside the SIM card?
This field is optional which contains the phone number of this SIM subscriber.

This information is meaningful when encoding MMS PDU.
In normal case, we will get a valid phone number or null if not available.
However, we got a "undefined" string with this CU SIM card.

That means somehow we don't interpret this property correctly and that's the reason why I need your help to collect these logs for further analysis.

However, after checking the log, I found that this log was stopped before entering SIM PIN this prevents me to see how all the fields in this SIM were interpret.

Hence, May I have your help to collect the main logcat again?
1. Start logcat before device boot up.
2. Enter SIM PIN and wait for 2min to ensure all the fields in SIM are loaded.

Thanks!

Comment 24

[SandKing]

Attachment: New main log: main_log.txt

Hi Bevis,
According to comment20 I fetch the new log,If you need any help, please feel free to contact me.
See new main log: "main_log.txt"

Comment 25

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

Hi SandKing,

Thanks for collecting this log.
I found the root cause is that we are not handling msisdn well the the MSISDN of the inserted SIM contains a valid Alpha-Id and an invalid dialling number:
32ffffffffffffffffffffffffffffffffffffffffffffffffffffff

In this case, we will set msisdn as undefined and will be identified as "undefined" string via XPCOM channel unexpectedly.

I'll update a try patch for you to validate the result.

Keep this NI on me.

Thanks!

Comment 26

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

Attachment: Patch v1: Decode invalid number from AND-Like EFs as empty string.

Hi SandKing,

Can you give this patch a trial to see if the issue is fixed?

Thanks!

Comment 27

[SandKing]

Hi Bevis,
This bug has been verified as pass on Flame 3.0 since I've built the new ROM with patch in comment 26.
Repro rate: 0/10


Flame 3.0(Pass):
Build ID               20150605131925
Gaia Revision          65369b217faac7d70c1a29100c4208c6d1db16e3
Gaia Date              2015-06-04 20:28:16
Gecko Revision         n/a
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.rose.20150605.131012
Firmware Date          Fri Jun  5 13:10:56 CST 2015
Bootloader             L1TC000118D0

Comment 28

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

Comment on attachment 8615252 [details] [diff] [review]
Patch v1: Decode invalid number from AND-Like EFs as empty string.

Thanks for your help, SandKing.

Hi Edgar,

May I have your review for this fix?

Thanks!

Comment 29

[Edgar Chen [:edgar]]

Comment on attachment 8615252 [details] [diff] [review]
Patch v1: Decode invalid number from AND-Like EFs as empty string.

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

Looks good, thank you.

Comment 30

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

update try server result:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=0c1a9f6509bb

Comment 31

[Pulsebot]

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

Comment 32

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

https://hg.mozilla.org/mozilla-central/rev/ace5ecc29a7c

Comment 33

[Elie]

Attachment: Verified video:1457.mp4

This bug has been verified as "pass" on  latest nightly build of Flame v3.0& Nexus5 v3.0 by the STR in Comment7.
Actual results:The unsent MMS you deleted does not appear again in Conversation view.

Reproduce rate: 0/10 
See attachment: 1457.mp4

Device: Flame v3.0 build(Pass)
Build ID               20150610160207
Gaia Revision          e3eaf72ccd1bfe6d60d37efde6d3b92c1dbc5ff9
Gaia Date              2015-06-10 03:13:33
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/95afddf894e3
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150610.193636
Firmware Date          Wed Jun 10 19:36:48 EDT 2015
Bootloader             L1TC000118D0

Device: Nexus5 v3.0 build(Pass)
Build ID               20150610160207
Gaia Revision          e3eaf72ccd1bfe6d60d37efde6d3b92c1dbc5ff9
Gaia Date              2015-06-10 03:13:33
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/95afddf894e3
Gecko Version          41.0a1
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150610.205837
Firmware Date          Wed Jun 10 20:58:56 EDT 2015
Bootloader             HHZ12f

Comment 34

[zouyi(Leave from Mozilla)]

Attachment: verified_v2.1.3gp

The bug cannot be reproduced on latest build of Flame v2.1 by the STR in comment 0.
See attachment: verified_v2.1.3gp
Reproduce rate: 0/5
Actual results:The unsent MMS you deleted in Step 3 is disappeared.
Device: Flame 2.1 build(pass)
Build ID               20150617001205
Gaia Revision          f8b848c82d1ed589f7a1eb5cc099830c867ff1d4
Gaia Date              2015-06-08 09:48:23
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/0ebea88c344d
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150617.035603
Firmware Date          Wed Jun 17 03:56:15 EDT 2015
Bootloader             L1TC000118D0

Comment 35

[Norry.L.F(Leave from Mozilla)]

Hi josh,

This bug seems to be a regression, could you have a look to determine whether to fixed on v2.2? 
Thanks :)

Comment 36

[Josh Cheng [:josh]]

Hi Bevis,
Can you help to raise 2.2 uplift request?\
Thanks!

Comment 37

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

The patch has to be re-based due to conflict to 2.2v.
I'll upload the patch for 2.2v uplift after verification.

Keep ni on me.

In addition, this issue only happened in the case that the MSISDN file in the inserted SIM is incorrectly as mentioned in comment 25 which shall not be happened in normal case.

Comment 38

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

Attachment: [2.2v] Patch v1: Decode invalid number from AND-Like EFs as empty string.

[rebase patch for v2.2 branch]

Hi SandKing,

May I have your help to verify if this patch fix the same problem in 2.2v?
(Note: To have 2.2v build, you have to run the following command and then apply this patch before building it in your local b2g directory)
$BRANCH=v2.2 ./config.sh flame-kk

Thanks!

Comment 39

[SandKing]

Hi Bevis,
This bug has been verified as pass on Flame 2.2 since I've built the new ROM with patch in comment 38, but one thing to note, this bug has never occured on Flame 2.2. So should I run the command  “BRANCH=v2.2 ./config.sh nexus-5-l”?

Flame 2.2 build:
Build ID               20150701144945
Gaia Revision          bd386f346eb1591fddbc84bf034b22700e7e2a58
Gaia Date              2015-06-30 15:53:15
Gecko Revision         n/a
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.rose.20150701.113340
Firmware Date          Tue Jul 1 11:34:23 CST 2015
Bootloader             L1TC000118D0

Comment 40

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

(In reply to SandKing from comment #39)
> Hi Bevis,
> This bug has been verified as pass on Flame 2.2 since I've built the new ROM
> with patch in comment 38, but one thing to note, this bug has never occured
> on Flame 2.2. So should I run the command  “BRANCH=v2.2 ./config.sh
> nexus-5-l”?
Yes, please help to try this one instead.
Thanks!

Comment 41

[SandKing]

Hi Bevis,
This bug has been verified as pass on Flame 2.2 since I've built the new ROM with patch in comment 38.
Repro rate: 0/10
Actual result:
The MMS can be deleted successful

Flame 2.2(Pass):
Build ID               20150702154657
Gaia Revision          bd386f346eb1591fddbc84bf034b22700e7e2a58
Gaia Date              2015-06-30 15:53:15
Gecko Revision         n/a
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.rose.20150702.151210
Firmware Date          Thu Jul 2 15:13:44 CST 2015
Bootloader             HHZ12f

Comment 42

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

(In reply to SandKing from comment #41)
> Hi Bevis,
> This bug has been verified as pass on Flame 2.2 since I've built the new ROM
> with patch in comment 38.
> Repro rate: 0/10
> Actual result:
> The MMS can be deleted successful
> 
Thanks for your quick update! :)

Comment 43

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

Attachment: [2.2v] Patch v2: Decode invalid number from AND-Like EFs as empty string.

test case update.

Comment 44

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

According to comment 19, comment 20, comment 25, instead of a regression, its more about the error handling of a invalid MSISDN in the inserted UICC.

Comment 45

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

Comment on attachment 8629195 [details] [diff] [review]
[2.2v] Patch v2: Decode invalid number from AND-Like EFs as empty string.

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): NA
User impact if declined: MMS cannot be sent properly if the MSISDN of the inserted SIM/UICC contains a name without a number. (It's not a normal use case, because user shall not be able to modify the MSISDN with the device in the market and this is only happened with MOZ-RIL included.
Testing completed: Y
Risk to taking this patch (and alternatives if risky): No.
String or UUID changes made by this patch:No.

Comment 46

[Josh Cheng [:josh]]

Comment on attachment 8629195 [details] [diff] [review]
[2.2v] Patch v2: Decode invalid number from AND-Like EFs as empty string.

It looks like very corner to me. I would like to wait until any partner request for this in 2.2. Thanks.

Comment 48

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

Comment on attachment 8629195 [details] [diff] [review]
[2.2v] Patch v2: Decode invalid number from AND-Like EFs as empty string.

This could block the smoke test in bug 1186829 who use the same test SIM for testing, so nominate approval again.

Comment 49

[Josh Cheng [:josh]]

Comment on attachment 8629195 [details] [diff] [review]
[2.2v] Patch v2: Decode invalid number from AND-Like EFs as empty string.

Approving as this would block smoke test per comment 48

Comment 50

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/7813ee50f3f6

Comment 51

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2r/rev/7813ee50f3f6

Comment 52

[Annabelle]

Attachment: verified_Nexus5_2.2.3gp

This bug has been verified as "pass" on  latest nightly build of  Nexus5 v2.2 by the STR in Comment 0.
Actual results: The unsent MMS you deleted does not appear again in Conversation view.

Reproduce rate: 0/10 
See video: verified_Nexus5_2.2.3gp

Device: Nexus5 v2.2 build(Pass)
Build ID               20150729152503
Gaia Revision          8f3749f875c5ed155ccbd630aa2ee4e8bc2a9400
Gaia Date              2015-07-29 14:28:57
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/e2a82fd90bc5
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150729.185707
Firmware Date          Wed Jul 29 18:57:27 EDT 2015
Bootloader             HHZ12f

Comment 53

[Annabelle]

Sorry