Closed
Bug 914440
Opened 11 years ago
Closed 11 years ago
[Buri][SMS] Device is not recognizing number for the same SMS conversation
Categories
(Core :: DOM: Device Interfaces, defect, P1)
Core
DOM: Device Interfaces
Tracking
()
People
(Reporter: sync-1, Assigned: airpingu)
References
Details
Attachments
(3 files)
(deleted),
image/png
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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 5•11 years ago
|
||
This is a threading issue.
Component: Gaia::SMS → DOM: Device Interfaces
Flags: needinfo?(gene.lian)
Product: Boot2Gecko → Core
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → gene.lian
Flags: needinfo?(gene.lian)
I think this bug is important and give our customers bad impressions if we can't fix it.
Comment 8•11 years ago
|
||
Gene, are we doing more work with phone number normalization for 1.2?
Flags: needinfo?(gene.lian)
Assignee | ||
Comment 9•11 years ago
|
||
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.
Flags: needinfo?(gene.lian)
Assignee | ||
Comment 10•11 years ago
|
||
This issue happen when: input number: "+5511987654321" 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?
Attachment #817771 -
Flags: feedback?(vyang)
Attachment #817771 -
Flags: feedback?(ctai)
Comment 11•11 years ago
|
||
I'm marking this as a blocker even if it's going to be duped to bug 914060.
blocking-b2g: koi? → koi+
Comment 12•11 years ago
|
||
(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: "+5511987654321" > 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 "+5511987654321", 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?
Assignee | ||
Comment 13•11 years ago
|
||
(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: "+5511987654321" > > 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 > "+5511987654321", 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•11 years ago
|
||
(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 > > "+5511987654321", 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•11 years ago
|
||
Comment on attachment 817771 [details] [diff] [review] Patch (WIP) Clear for now.
Attachment #817771 -
Flags: feedback?(vyang)
Attachment #817771 -
Flags: feedback?(ctai)
Assignee | ||
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Target Milestone: --- → 1.3 Sprint 3 - 10/25
You need to log in
before you can comment on or make changes to this bug.
Description
•