Bug filed during certification in Spain. Device Ikura, Buildid "20130321070205" gecko commit: b5183c99228bdc5be33340e359efd1b4f0859e92 gaia commit: 577d13088ebdbd353d13910d3317e713a140415b PROCEDURE See also the screenshots attached while following the steps. Step 1 --> in 5th SMS we have 2 characters more if we want to write any more. Step 2--->when press next key , Counter of characters change to 154 available for the same SMS(5th) Step 3--->We write in same SMS , and the cunter is down to 150 characters available. Step 4--->When push one more key the counter of SMS concatenated change to 6 and the digits available for this SMS is 149 EXPECTED The counter of digits and SMSs work fine ACTUAL Counter of characters in concatenated SMS is not working correctly.

Unagi is also affected, v1.0.1 and with commercial RIL There is also a problem when changing from SMS1 to SMS2, from SMS2 to SMS3 and so on. When typping to reach the end of the sms and change to another this is what the counter shows: SMS1: 1/1, 0/1 -> SMS2: 147/2,..... 3/2, 2/2, 154/2, 153/2 -> SMS3: 152/3,....3/3, 2/3, 154/3,153/3,152/3 -> SMS4: 151/4..... Just in case it could help, this is the method taking and showing that info: getSegmentInfoForText(text)

Alhad, please have a look. Requesting nomination for TEF as this seems like a basic issue.

If I can clear some expectations, there are various rules that must be taken into account when verifying this calculation. For a 7-bit-mode message, one SMS has a max length of 160 char, but as soon as you use more than one SMS, the max length for one SMS goes down to 153. So SMS2 with 1 character should show 145/2. MozRIL does that correctly, and as far as I see this is correct too for the following SMS. This is also correct for 16-bit-mode messages (67 char per message in concatenated mode). AFAIK MozRIL does not support 8-bit-mode messages but this is probably not necessary. So I think this is basically what's expected for the Commercial RIL too.

(In reply to Julien Wajsberg [:julienw] from comment #7) > MozRIL does that correctly, and as far as I see this is correct too for the > following SMS. So I think this is basically what's expected for the Commercial > RIL too. Or maybe we should move these logic out of RadioInterfaceLayer to some shared service. SmsService itself is a appropriate place for this. This might save some problems in commercial RIL, but will certain bring interface changes to it, too.

No more RIL interface changes for v1.0.1 please, we are well beyond that. Ideally not for v1.1 as well. They are quite painful for all.

Daniel, can you talk with Michael? We either need to take a RIL change or ship with this bug it sounds like. Or if there's a workaround, who would know?

Alhad will be looking at this issue shortly.

(In reply to Dietrich Ayala (:dietrich) from comment #10) > Daniel, can you talk with Michael? We either need to take a RIL change or > ship with this bug it sounds like. > > Or if there's a workaround, who would know? I think comment 9 was in response to the suggested change of placement for the logic. I assume the target is still to fix this in commercial RIL as I think no interface change is required for this. Correct me I am wrong Anshul/Alhad.

Yes, we'll fix this and no interface change needed or desired

The issue would be resolve in AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.079 for TEF and AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.067 for Leo

Reproducible in the following build in Inari : Gecko http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/6bac24e14538 Gaia c883af5ecd0998f78d9aaa4c2337c842e1dbb5a0 BuildID 20130416070200 Version 18.0 This happens while transitioning from 4th SMS to 5th SMS as well (wrong count of characters available and wrong count of number of concatenated messages)

Sreenidhi, did you try on the AU I recommended in comment #15?

Hi Anshul, No, I did not try it on the AU in Comment 15. Will do so and check.

Hi, Just tested it again with Ikura: Build id: 20130423004103. Gaia: e14c36bb AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.083 And, unfortunately the bug is still seen. Please see video file attached. Thanks

so I reopen.

Isabel, I have a suspicion that you are not using AU 83.

Hi Anshul, I have checked this issue with yesterday's build (that I've confirmed it's based on AU 83) and the behaviour is exactly the one described in the bug. So, I believe that Isabel is right.

Hi Perez, is it possible that whoever gave you the build did something wrong while making the build and didn't pull the correct commercial RIL code. I am certain that the code you are running doesn't belong to AU 83 by looking at the logs. Also please see my attachment in comment #23 with AU 83 and I can not reproduce this issue.

(In reply to Anshul from comment #26) > Hi Perez, Please, call me Juan directly :) > is it possible that whoever gave you the build did something wrong > while making the build and didn't pull the correct commercial RIL code. I am > certain that the code you are running doesn't belong to AU 83 by looking at > the logs. I will verify this (thanks!). Dear colleagues, could you please check the RIL version you really used in yesterday's version (20130423)? Although in the version name it appears 19.083, it seems we are not really including this RIL. -->ni for Firefox_Mozilla@126.com

The OEM will need around 5 days to prepare the build and do the verification. It means, we need to fix it by May 21th. Thanks.

Solved in the build 20130426093145 with the ril LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.085

sorry, I forgot to indicate the device. the bug was tested with the device Inari

(In reply to rafael.marquez from comment #29) > Solved in the build 20130426093145 with the ril > LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.085 Verified also in Ikura, same build --> erasing ni for Firefox_Mozilla@126.com