isabelrios Reporter
	Description • 11 years ago

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.

	isabelrios Reporter
	Comment 5 • 11 years ago

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)

	Anshul
	Comment 6 • 11 years ago

Alhad, please have a look.

Requesting nomination for TEF as this seems like a basic issue.

	Julien Wajsberg [:julienw]
	Comment 7 • 11 years ago

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.

	Vicamo Yang [:vicamo][:vyang]
	Comment 8 • 11 years ago

(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.

	Michael Vines [:m1] [:evilmachines]
	Comment 9 • 11 years ago

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.

	Dietrich Ayala (:dietrich)
	Comment 10 • 11 years ago

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?

	Anshul
	Comment 11 • 11 years ago

Alhad will be looking at this issue shortly.

	Daniel Coloma:dcoloma
	Comment 12 • 11 years ago

(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.

	Michael Vines [:m1] [:evilmachines]
	Comment 13 • 11 years ago

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

	Anshul
	Comment 15 • 11 years ago

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

	Sreenidhi
	Comment 16 • 11 years ago

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)

	Anshul
	Comment 17 • 11 years ago

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

	Sreenidhi
	Comment 18 • 11 years ago

Hi Anshul, 

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

	isabelrios Reporter
	Comment 19 • 11 years ago

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

	Julien Wajsberg [:julienw]
	Comment 21 • 11 years ago

so I reopen.

	Anshul
	Comment 24 • 11 years ago

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

	Juan Perez-Bedmar [:juanpbf]
	Comment 25 • 11 years ago

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.

	Anshul
	Comment 26 • 11 years ago

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.

	Juan Perez-Bedmar [:juanpbf]
	Comment 27 • 11 years ago

(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

	Kai-Chih Hu [:khu]
	Comment 28 • 11 years ago

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.

	rafael.marquez
	Comment 29 • 11 years ago

Solved in the build 20130426093145 with the ril LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.085

	rafael.marquez
	Comment 30 • 11 years ago

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

	Juan Perez-Bedmar [:juanpbf]
	Comment 31 • 11 years ago

(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