Autofill format of phonenumber drops formatting (international prefix, spaces, dash)

victorandree

Hi!

I've added a phone number to my identity card in 1Password. To make it usable internationally, I want to use "+" as an international prefix. For example "+46 73 123 45 67" for a Swedish cellphone number. When this gets autofilled using 1Password X, it always drops the "+" sign and the spaces, turning it into "46731234567". Native formatting uses "-" ("073-123 45 67") which also gets stripped.

I can appreciate that formatting phone numbers is hard, and that a lot of websites have bad input fields for them. I'm guessing 1Password tries to do its best to use a safe format. However, by excluding "+", the value is simply wrong.

I think either 1Password should:

• Keep the + prefix, since it's pretty well established as an international prefix.
• Replace + prefix with "00" which is the standard international prefix (but which, ironically, doesn't work in every country which is why you'd use "+").

For now, I'll format the number as "0046 73 123 45 67" in 1Password myself.

---

1Password Version: 7.6
Extension Version: 1.22.3
OS Version: macOS 11.0.1
Sync Type: 1password.com

BrBill

Agree!

ag_michaelc

Thank you for the feedback, @BrBill and @victorandree! Do you have a few examples of sites where this has caused you trouble, so we can make note of them for testing purposes?

BrBill

I replied by mistake. Sorry, I have too many sites to remember which have caused it.

ag_ana

No worries @BrBill, if you end up remembering them, please feel free to let us know :+1:

victorandree

@ag_ana Once you go looking for it, hard to find concrete examples... But it's really any phone number input.

• A basic demo on CodePen
• Many websites seem to split the phone number into 2 country codes: country code and phone number. This applies to the sign-ups of, for example, DHL and UPS. For those sites it'd be great if only the local part of the phone number were autofilled. I guess websites should mark that up properly (https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete)...

ag_yaron

Hey @victorandree ,

When a website utilizes a field that is of type="tel", it will often not accept any characters other than digits. Here's one for example: https://callhippo.com/signup
That is why we drop any other character expect for digits. If we do add hyphens and + signs, the form might fail to submit, which is rather annoying in most cases :)

We'll try to look into it and see if we can find a better balance though. Thanks for bringing this up! If you have any more examples of websites as you encounter them, feel free to add them here so we'll have more use cases and examples of websites and how they implement their form.

victorandree

@ag_yaron Right, I get that many websites aren't as accepting as they should be. Though, your specific example (https://callhippo.com/signup) actually seems to accept both "+" and spaces (inline validation and at submission) :) It does separate the international prefix, but also figures it out if I enter an international number.

Here's some decently popular services that are troublesome:

• Signing up for Microsoft (through e.g. Azure at https://signup.azure.com/signup)
• Creating an Apple ID (https://appleid.apple.com/account)
• UPS (https://www.ups.com/doapp/signup)

All of them do seem to put the international prefix in its own field, though, so that might be relevant to consider.

ag_yaron

Hey @victorandree ,

The website I gave as an example allows typing spaces and pluses, but it will throw an error if you try to submit the form saying invalid number.

Same goes for the other websites you've shared here if we would autofill your number as you've written it in 1Password (e.g. +46 73 123 45 67). You can try copy and paste that number as is into these websites and see the error when you try and send the form (or when you move to another field).

That is exactly why we save you the trouble of having to manually edit the number and remove the plus for you :)
And yeah, the international prefix is a standard that we do intend to follow and perhaps autofill with its own field in the future. Perhaps that is the balance we need here.