AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.184 Firefox os v1.1 Mozilla build ID:20130806071254 DEFECT DESCRIPTION: MMS APN settings: if the proxy address is given with leading zero's MMS message cannot be downloaded REPRODUCING PROCEDURES: MMS APN settings: If the MMS proxy ip address is given with leading zero's MMS message cannot be downloaded e.g. 171.028.023.131 instead of 171.28.23.131 Step: Use unicom sim card 1.Settings->Cellular&Data->Message settings 2.Change APN MMS proxy from 10.0.0.172 to 010.000.000.172->tap OK 3.Download or send an MMS,can't download and send successfully->KO EXPECTED BEHAVIOUR: It should send and download MMS successfully ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: Mid REPRODUCING RATE: 5/5 For FT PR, Please list reference mobile's behavior:

http://en.wikipedia.org/wiki/Dot-decimal_notation In information technology, an integer number that starts with the digit 0 is often interpreted as a number in octal representation. Therefore, if an IP address component is written with a leading 0 digit, it may be interpreted incorrectly by some utility programs.[4] For example, the representation 022.101.031.153, when parsed as octal, would be equivalent to the decimal notation 18.101.25.153. Well, so why on earth do you expect "171.028.023.131" should work as usual?

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #1) > http://en.wikipedia.org/wiki/Dot-decimal_notation > > In information technology, an integer number that starts with the digit 0 > is > often interpreted as a number in octal representation. Therefore, if an IP > address component is written with a leading 0 digit, it may be interpreted > incorrectly by some utility programs.[4] For example, the representation > 022.101.031.153, when parsed as octal, would be equivalent to the decimal > notation 18.101.25.153. > > Well, so why on earth do you expect "171.028.023.131" should work as usual? From information technology point of view, the explation above is exactly 100% correct. However, technology should server for human being. Human talk on decimal but not octal. For user, 022 is same as 22. Technology should understand 022 as decimal digit (22), but not treat it as octal digit (18).

Vicamo, in the text, there is the word "incorrectly" ;) This means that programs behaving like this are behaving incorrectly. I'm pretty sure users can write eg 21 as 021, because they may think it's necessary to write 3 digits, or because the carrier's help shows it like this. We shoul work as expected here. Is it a bug from Settings or from the MMS subsystem ? Or elsewhere ?

As a workaround we could remove any leading zero in the settings app, but this wouldn't fix it if the default value has leading zero.

Putting in the c= to get this into sprint backlog but it's not a critical blocker, more of a new feature request.

per comment 4, this seem like an easy fix. koi+ for v1.2 convergence stage

(In reply to Julien Wajsberg [:julienw] from comment #3) > Vicamo, in the text, there is the word "incorrectly" ;) This means that > programs behaving like this are behaving incorrectly. > > I'm pretty sure users can write eg 21 as 021, because they may think it's > necessary to write 3 digits, or because the carrier's help shows it like > this. We shoul work as expected here. > > Is it a bug from Settings or from the MMS subsystem ? Or elsewhere ? Just doing a small test: $ ping 010.243.027.076 PING 010.243.027.076 (8.243.23.62) 56(84) bytes of data. Do we really want to support this ? It's just a buggy IP address.

Alexandre, please understand that users of our phone are likly not the users of the "ping" program. However, I agree this should not be handled by gecko but rather by the gaia Settings app. When entering IPs in Windows' network panel, such leading 0 are simply silently discarded iirc. We should do the same.

(In reply to Julien Wajsberg [:julienw] from comment #8) > Alexandre, please understand that users of our phone are likly not the users > of the "ping" program. > > However, I agree this should not be handled by gecko but rather by the gaia > Settings app. When entering IPs in Windows' network panel, such leading 0 > are simply silently discarded iirc. We should do the same. I'm fine with the proposed behavior.

Taking, will make a patch per comment #8. Please tell me if anyone has already working on it.

afaik nobody has worked on this yet, thanks Rex !

This patch checks not only mmsproxy input, but also httpproxy input for all APN settings (Data, Message, and A-GPS for now) to eliminate padding 0 if they are IP. Arthur would you mind helping review this patch?

Comment on attachment 795918 [details] patch Thanks for the patch, Rex! Please check my comments in github.

Comment on attachment 795918 [details] patch Thank you Arthur, I modified based on our discussion (use onchange rather than onblur instead though) may you take a look again?

Comment on attachment 795918 [details] patch Thanks for the effort! r=me. Please squash the commits and rebase to the current master before merging.

Thank you Arthur! merged here: https://github.com/mozilla-b2g/gaia/commit/ecd9abaebb90c11b9b96daeb04e7aefeeb9f8abc Notice that there are some rebase work before merging. It's just indent and linter change so I tested and merged directly.

Just as a reference, the La Poste Mobile MVNO provides MMS configuration with leading 0 on its webpage: « Nom du profil : MMS La Poste Mobile APN (point d'accès) : mmsdebitel Type d'authentification (sécurité) : sans Url serveur (MMSC) : http://mmsdebitel Adresse IP : 010.143.156.003 Port IP : 8080 ou 9201 Identifiant : laisser champ vide Mot de passe : laisser champ vide »