813621 - B2G Contacts: Applying PhoneNumberJS to Contacts DB

Status: RESOLVED DUPLICATE of bug 815833

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

Description

[Borja Salguero [:borjasalguero]]

It's needed in order to remove PhoneNumberJS from Gaia. We need a way of storing the 'typed' phone number by the user and the normalized one.
Once we request 'Give me the contact with phone number 123123123' Gecko will apply PhoneNumberJS, being in charge of having an univocal way of managing normalized phone numbers.

Comment 1

[Dietrich Ayala (:dietrich)]

Really need more information here.

Why do we need to remove PhoneNumberJS from Gaia?

Why does this *need* to happen for V1?

Comment 2

[Borja Salguero [:borjasalguero]]

Answers inline:

> Why do we need to remove PhoneNumberJS from Gaia?

In SMS App (this problem is in Call log as well) we need to update the UI with the info retrieved from Contacts API. Scenario:
- Store in Contacts App the following contact:
NAME : Jesper López
PHONE NUMBER: 612123123
- Send a SMS to a phone number 0034612123123
- SMS App needs to retrieve all info from the contact with the phone number 0034612123123

What is the problem here?
As Contacts DB does not have PhoneNumberJS applied, if I request to Contacts API with the internationalized version that I typed (0034612123123) Im gonna retrieve 0 Contacts, due to the API does not have the capability of getting the 'normalized/internationalized' version of the phone number.

How is solved currently?
We have a workaround in Gaia. Instead of request Contacts API with a filter 'equals to 0034612123123', we create all possibilities given a number with PhoneNumberJS and we request with 'contains [0034612123123,+34612123123,612123123]'. This 'hack' has some problems, due to the number ''612123123" could be part of other international number that you could have in your agenda, and we are keeping the library in SMS App, so Starting time is not optimized.

> Why does this *need* to happen for V1?
We need a common way of storing and managing phone numbers in Gecko, if we apply PhoneNumberJS to Contacts & SMS DB adding a field with the 'international/normalized phone number', we will be able to remove all workarounds in Gaia (including the whole library! ) and we are going to have a consistent an univocal way of managing normalized phone

Comment 3

[Borja Salguero [:borjasalguero]]

Probably we could mark this one as duplicated, because the patch is in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=815833

Comment 4

[Dietrich Ayala (:dietrich)]

(In reply to Borja Salguero [:borjasalguero] from comment #2)
> > Why does this *need* to happen for V1?
> We need a common way of storing and managing phone numbers in Gecko, if we
> apply PhoneNumberJS to Contacts & SMS DB adding a field with the
> 'international/normalized phone number', we will be able to remove all
> workarounds in Gaia (including the whole library! ) and we are going to have
> a consistent an univocal way of managing normalized phone

This does not seem enough to hold back the release of V1, and not enough of a reason to justify the risk that comes with such big and new Gecko changes at this time.

Perhaps I am not fully understanding. Vivien, can you please take a look and provide input?

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

If we don't have one source of truth for normalized phone numbers, we're going to create a nightmare for ourselves that will last years into the future.  Apps won't know what to expect when passing to or receiving numbers from DOM APIs.  They would have to maintain O(n-versions) normalization hacks.  Gecko won't be able to fully own normalization in the future, because that would require DB upgrades that could break existing content.

QA'ing all code that deals with phone numbers would be an O(n) problem because it would have to be repeated 100% for all apps that have to deal with them.

So, I'm strongly in favor of bb+.  If integrating this would cause us to slip release by a day, I think it would be worth it.  If it caused us to slip by, say, a month, I would feel slightly differently.  But neither is the case.

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #5)
> QA'ing all code that deals with phone numbers would be an O(n) problem
> because it would have to be repeated 100% for all apps that have to deal
> with them.

Actually O(n^2), because phone numbers are part of the language apps use to communicate between themselves.

Comment 7

[Ben Francis [:benfrancis]]

If this really blocks bug 796618 then it needs to be scheduled for C2 and needs an assignee. Nominating for blocking-basecamp because it's currently blocking a C2 bug.

Comment 8

[Andrew Overholt [:overholt]]

Gregor, we talked about this in triage and decided it's at least as important as doing this for the SMS app.  Therefore we're blocking on it and giving it to you.  If you're not the best owner, please assign to nobody.  Thanks!

Comment 9

[Gregor Wagner [:gwagner]]

This is already fixed in bug 815833. Or do we need some additional features?

Comment 10

[JP Rosevear [:jpr]]

Closing based o #9 - If there is more work to do here other than bug 815833, please reopen.

Comment 11

[Borja Salguero [:borjasalguero]]

Scenario with Spanish SIM Card.
- Store one Contact with 612123123
- Request to Contact API with the internationalized one:
      var options = {
        filterBy: ['tel'],
        filterOp: 'equals',
        filterValue: '[phone]'
      };

- Call to API:
window.navigator.mozContacts.find(options);

EXPECTED: Retrieve the contact

CURRENTLY: No contact retrieved for the internationalized version of the phone number

Comment 13

[Gregor Wagner [:gwagner]]

(In reply to Borja Salguero [:borjasalguero] from comment #11)
> Scenario with Spanish SIM Card.
> - Store one Contact with 612123123
> - Request to Contact API with the internationalized one:
>       var options = {
>         filterBy: ['tel'],
>         filterOp: 'equals',

Equal currently only checks the number you entered. 'contains' should work.

>         filterValue: '[phone]'
>       };
> 
> - Call to API:
> window.navigator.mozContacts.find(options);
> 
> EXPECTED: Retrieve the contact
> 
> CURRENTLY: No contact retrieved for the internationalized version of the
> phone number