914440 - [Buri][SMS] Device is not recognizing number for the same SMS conversation

Status: RESOLVED DUPLICATE of bug 914060

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

Description

[sync-1]

Mozilla build ID:20130902041201
 DEFECT DESCRIPTION: When user write SMS to number with 9 numbers in Brazil and then the receiver answer the SMS, network is adding "+5511" so when the SMS is received, device is not recognizing the SMS belongs to the same conversation.
 
  EXPECTED BEHAVIOUR: Device must recognize the SMS received from "same number" belongs to same converstion and place on the same screen.
 
 See attach logs and Picture.
 
  REPRODUCING PROCEDURES:
 1.- Send SMS from Fire Fox to other number with 9 digits (brazilian format).
 2.- Destination number answer the SMS
 3.- Receive SMS in Unit under Test.
 4.- You will see than VIVO network add "+5511" in the destination number...device must recognize it as same number.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT: Wrong MMI
 
  REPRODUCING RATE: 100%
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Clone from brother

Comment 2

[sync-1]

Attachment: Screen shot SMS interface

Comment 3

[sync-1]

Clone from brother

Comment 4

[sync-1]

Attachment: qxdm LOG

Comment 5

[Julien Wajsberg [:julienw]]

This is a threading issue.

Comment 6

[David Scravaglieri [:scravag]]

This is a topic for koi version

Comment 7

[田旻]

I think this bug is important and give our customers bad impressions if we can't fix it.

Comment 8

[Andrew Overholt [:overholt]]

Gene, are we doing more work with phone number normalization for 1.2?

Comment 9

[Gene Lian (I already quit Mozilla)]

Phone number comparison is not a new feature. Instead, it's always necessary to help us assign the messages the correct thread. I think this one should still be marked as blocker.

Comment 10

[Gene Lian (I already quit Mozilla)]

Attachment: Patch (WIP)

This issue happen when:

  input number: "[phone]"
  stored number: "987654321"

the .nationalNumber of the input number is "11987654321" which is not a suffix of the stored number, thus failing to match.

Bug 914060 is trying to solve the same issue. As my best understanding from Vicamo and Ctai, we will do exactly match by .nationalMatchingFormat in the long run. This WIP patch here shows a possible way to solve this issue, which should be going to be part of the complete solution in bug 914060.

I'd suggest marking this as duplicate of bug 914060. Vicamo and Ctai, what do you think?

Comment 11

[Andrew Overholt [:overholt]]

I'm marking this as a blocker even if it's going to be duped to bug 914060.

Comment 12

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

(In reply to Gene Lian [:gene] (needinfo? encouraged) from comment #10)
> Created attachment 817771 [details] [diff] [review]
> Patch (WIP)
> 
> This issue happen when:
> 
>   input number: "[phone]"
>   stored number: "987654321"
> 
> the .nationalNumber of the input number is "11987654321" which is not a
Hi, Gene,
We match international number or national number in bug 914060, not nationalMatchingFormat. Please see |fuzzyMatch| in PhoneNumberUtils. Can you parse "987654321" with MCC 724(Brazil)?
If the international number or national number are the same as "[phone]", bug 914060 can solve this bug.

> suffix of the stored number, thus failing to match.
> 
> Bug 914060 is trying to solve the same issue. As my best understanding from
> Vicamo and Ctai, we will do exactly match by .nationalMatchingFormat in the
> long run. This WIP patch here shows a possible way to solve this issue,
> which should be going to be part of the complete solution in bug 914060.
> 
> I'd suggest marking this as duplicate of bug 914060. Vicamo and Ctai, what
> do you think?

Comment 13

[Gene Lian (I already quit Mozilla)]

(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #12)
> (In reply to Gene Lian [:gene] (needinfo? encouraged) from comment #10)
> > Created attachment 817771 [details] [diff] [review]
> > Patch (WIP)
> > 
> > This issue happen when:
> > 
> >   input number: "[phone]"
> >   stored number: "987654321"
> > 
> > the .nationalNumber of the input number is "11987654321" which is not a
> Hi, Gene,
> We match international number or national number in bug 914060, not
> nationalMatchingFormat. Please see |fuzzyMatch| in PhoneNumberUtils.

To be specific, the following logic in fuzzyMatch does what I'm talking about for nationalMatchingFormat (please see PhoneNumberUtils.parse()).

  let countryName = this.getCountryName();
  let ssPref = "dom.phonenumber.substringmatching." + countryName;
  if (Services.prefs.getPrefType(ssPref) == Ci.nsIPrefBranch.PREF_INT) {
    let val = Services.prefs.getIntPref(ssPref);
    if (normalized1.length > val && normalized2.length > val
       && normalized1.slice(-val) === normalized2.slice(-val)) {
      return true;
    }
  }

> Can you parse "987654321" with MCC 724(Brazil)?
> If the international number or national number are the same as
> "[phone]", bug 914060 can solve this bug.

No, internationalNumber is null and nationalNumber is 987654321. But as far as I know from Vicamo, we'll eventually compare the suffix by "dom.phonenumber.substringmatching." if the international numbers don't match. Right?

Comment 14

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Gene Lian [:gene] (needinfo? encouraged) from comment #13)
> (In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #12)
> > Can you parse "987654321" with MCC 724(Brazil)?
> > If the international number or national number are the same as
> > "[phone]", bug 914060 can solve this bug.
> 
> No, internationalNumber is null and nationalNumber is 987654321. But as far
> as I know from Vicamo, we'll eventually compare the suffix by
> "dom.phonenumber.substringmatching." if the international numbers don't
> match. Right?

Yes, and maybe we don't have to touch "dom.phonenumber.substringmatching.*" at all because |parse()| has prepared 'nationalMatchingFormat' for us.  Let's discuss in the review of bug 914060, and do our best effort to eliminate extra work to solve this bug.

Comment 15

[Vicamo Yang [:vicamo][:vyang]]

Comment on attachment 817771 [details] [diff] [review]
Patch (WIP)

Clear for now.