1474920 - Saving a phone number will add "+1" prefix by default

Status: NEW

(Firefox :: WebPayments UI, defect, P3)

Description

[Daniel Bodea [:danibodea]]

Preconditions:
a. Set the pref dom.payments.request.enabled to "true";
b. Set the pref dom.payments.loglevel to “Debug” to increase the verbosity of console messages.
c. Make sure you have at least one Shipping Address and one Shipping Option saved in your browser (Saved Cards).

Steps to reproduce:
1. Lunch Firefox.
2. Open "https://rsolomakhin.github.io/pr/expl/".
3. Click the "Buy" button.
4. "Your Payment" screen is displayed; Click the "Add" link/button from the Shipping Address" section.
5. The "Add Shipping Address" screen is displayed; Input valid data in all the fields; Input "1234567890" in the Phone Number input box and click "Save".
6. The "Your Payment" screen is displayed again;
7. Click on the "Shipping Addresses" section to open the drop-down with the available (saved) shipping addresses.

Actual: The phone number appears saved as: "[phone]".

Expected: The phone number is saved as it was introduced: "1234567890".

Comment 1

[Matthew N. [:MattN]]

This is expected while we only support Canada and the U.S., otherwise the appropriate country code should be added instead of "1". We could display the number differently to the user but the +1… version is what we will return and matches Form Autofill. We are trying to follow E.164 when possible.

"When setting the payerPhone value, the user agent SHOULD format the phone number to adhere to [E.164]."
https://w3c.github.io/payment-request/#user-accepts-the-payment-request-algorithm

Related spec issue: https://github.com/w3c/payment-request/issues/652

UX, what do you think? Is it fine to normalize upon saving or should we only normalize behind the scenes when passing the number to the merchant (who may then display it themselves in the normalized way).

Comment 2

[Jacqueline Savory [:jsavory] UX]

I don't think its a problem to normalize upon saving, in my opinion the plus sign should not confuse anyone if it appears in front of the phone number. 

Another option though is we could have the plus button shown but not editable in the phone number field when the user activates the text field. Just to show that it will be added after.

Comment 3

[Eric Pang [:epang] UX]

(In reply to Jacqueline Savory [:jsavory] UX from comment #2)
> I don't think its a problem to normalize upon saving, in my opinion the plus
> sign should not confuse anyone if it appears in front of the phone number. 
> 
> Another option though is we could have the plus button shown but not
> editable in the phone number field when the user activates the text field.
> Just to show that it will be added after.

The second suggestion sounds good if we can do it.  If we known the country code we should show it.  I also agree it should not be editable.

Comment 4

[Matthew N. [:MattN]]

(In reply to Eric Pang [:epang] UX from comment #3)
> (In reply to Jacqueline Savory [:jsavory] UX from comment #2)
> > I don't think its a problem to normalize upon saving, in my opinion the plus
> > sign should not confuse anyone if it appears in front of the phone number. 
> > 
> > Another option though is we could have the plus button shown but not
> > editable in the phone number field when the user activates the text field.
> > Just to show that it will be added after.
> 
> The second suggestion sounds good if we can do it.  If we known the country
> code we should show it.  I also agree it should not be editable.

I think you and Jacqueline are saying two different things… I think Jacqueline is only talking about the "+" but it sounds like you are talking about the whole country code "+1". The former is something we could do but would be incorrect if the user doesn't type the country code. The latter doesn't really work as we have no idea which country the phone number will be from. The country of the address doesn't have to be related to the phone number.

e.g. +[555-555-5678]    <= this doesn't make sense while a user is typing since we shouldn't have a "+" without a country code

When the user came back to edit we would have normalized it to +[15555555678] but I think it's more confusing with the + on the outside for users who are used to typing the +.

Thoughts?