897309 - [Buri][Messages]Can not send message to 10010

Status: RESOLVED DUPLICATE of bug 885280

(Core :: DOM: Device Interfaces, defect, P1)

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.164
 Firefox os  v1.1
 Mozilla build ID:20130715070218
 DEFECT DESCRIPTION:
 1.when send message to 10010,it seem does not reaction(send message defeat).
 2.wait a moment,10010 well reply a message,but can not see it at message list.
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[田旻]

It was caused by the error in MobileMessageDatabaseService.js.
line#845： let needles = allPossibleAddresses.slice(0);
let request = aParticipantStore.index("addresses").get(needles.pop());

Sometimes, needles.pop() returns null, thus leads to this bug.

Comment 2

[Alex Keybl [:akeybl]]

(In reply to sync-1 from comment #0)
>   REPRODUCING RATE:

What's the reproduction rate here? Comment 1 suggests this isn't 100% reproducible.

Comment 3

[田旻]

(In reply to Alex Keybl [:akeybl] from comment #2)
> (In reply to sync-1 from comment #0)
> >   REPRODUCING RATE:
> 
> What's the reproduction rate here? Comment 1 suggests this isn't 100%
> reproducible.

Some telephone numbers which is more than 3 bits will leads this problem, because  allPossibleAddresses( for this numbers) is an Array like ['10010', null]. You can never request a indexDB to return any legal results with a null index request. It's unreasonable. And that is just the reason lead to this problem. 
When you just use the number '10010' to send a message, it's a 100% reproduction.

Meanwhile, I think it's easy to deal with. We just need to add some judgement to ensure needles.pop() return a legal value, as follows:

      var ads=needles.pop();  
      if(!ads)ads=needles.pop(); 
      let request = aParticipantStore.index("addresses").get(ads);

Comment 4

[Alex Keybl [:akeybl]]

Sounds like a blocker given comment 3. Anthony, can you help with reassignment here?

Comment 5

[Rick Waldron [:rwaldron]]

Updating the product and component.

Comment 6

[Anthony Ricaud (:rik)]

Alexandre: Can you help on this bug?

Comment 7

[:gerard-majax]

I'm not sure I understand how to reproduce this. Would it work with any SIM and network ?

Comment 8

[:gerard-majax]

(In reply to 田旻 from comment #3)
> (In reply to Alex Keybl [:akeybl] from comment #2)
> > (In reply to sync-1 from comment #0)
> > >   REPRODUCING RATE:
> > 
> > What's the reproduction rate here? Comment 1 suggests this isn't 100%
> > reproducible.
> 
> Some telephone numbers which is more than 3 bits will leads this problem,
> because  allPossibleAddresses( for this numbers) is an Array like ['10010',
> null]. You can never request a indexDB to return any legal results with a
> null index request. It's unreasonable. And that is just the reason lead to
> this problem. 
> When you just use the number '10010' to send a message, it's a 100%
> reproduction.
> 
> Meanwhile, I think it's easy to deal with. We just need to add some
> judgement to ensure needles.pop() return a legal value, as follows:
> 
>       var ads=needles.pop();  
>       if(!ads)ads=needles.pop(); 
>       let request = aParticipantStore.index("addresses").get(ads);

I don't understand precisely what you mean, especially « Some telephone numbers which is more than 3 bits ». Is it related to a specific SIM card ? 

Can you provide adb logcat output with debug enabled in:
 - dom/mobilemessage/src/ril/MobileMessageDatabaseService.js
 - dom/phonenumberutils/PhoneNumberUtils.jsm
 - dom/phonenumberutils/PhoneNumber.jsm

Comment 9

[:gerard-majax]

With Gecko 18 as of yesterday, logcat on my Inari with a Bouygues Telecom SIM shows:

I/Gecko   (  393): MobileMessageDatabaseService: findParticipantRecordByAddress: allPossibleAddresses = ["10010"]

I have no "null" element in the array.

Comment 10

[:gerard-majax]

Given the build id of comment #1, I'm starting to wonder whether it's not a regression from bug 885280.

Comment 11

[:gerard-majax]

Description in https://bugzilla.mozilla.org/show_bug.cgi?id=885280#c38 shows a very similar report than the current bug, I'm building a gecko-18 with the first version of bug 885280's patch, that matches the present bug report's buildid, to check that I can reproduce the issue and that this is effectively a regression that has been fixed.

Comment 12

[:gerard-majax]

I still cannot reproduce, but the description of bug 885280 really makes me wondering it has been fixed.

Can you retry with a newer version ? Thanks !

Comment 13

[田旻]

Attachment: sms10010.log

This problem is sim card related. May be different sim card return different value when system request to it.  I have attach the file you need. Please check.

Comment 14

[:gerard-majax]

(In reply to 田旻 from comment #13)
> Created attachment 782383 [details]
> sms10010.log
> 
> This problem is sim card related. May be different sim card return different
> value when system request to it.  I have attach the file you need. Please
> check.

Can you retry with a newer version, please ? Because I clearly cannot reproduce this here :(

Comment 15

[田旻]

Actually, I have fixed this pr on our side. However, I will remove the patch and test it on the newest build (Mozilla build ID:20130722070207) again.
I will give you some feedback soon.

Comment 16

[田旻]

(In reply to Alexandre LISSY :gerard-majax from comment #14)
> (In reply to 田旻 from comment #13)
> > Created attachment 782383 [details]
> > sms10010.log
> > 
> > This problem is sim card related. May be different sim card return different
> > value when system request to it.  I have attach the file you need. Please
> > check.
> 
> Can you retry with a newer version, please ? Because I clearly cannot
> reproduce this here :(
Yes, after test on the new build (Mozilla build ID:2013072207020), it works well now.

Comment 17

[:gerard-majax]

Thanks !