Tested the issue on Latest Stable# 58.0.3029.81 and Latest Canary# 60.0.3082.3 on Windows, Mac and Linux.
This is a Non-Regression Issue seen on M30 builds# 30.0.1549.0, changing the status to Untriaged so that the issue would get addressed.
Thank You.

The behavior you are seeing is ... a "feature". It's not us. It's the PDF file. If you uncompress it, you can look inside and see the phone number field is being formatted with AFSpecial_Format(2) / AFSpecial_Keystroke(2), which means it wants the field in a phone number format. All the documentation I can find says its a US number format.

Trying to fill the form in a US edition of Acrobat Reader shows the same behavior as Chrome's PDF Viewer. Evince presumably doesn't implement AFSpecial_Format/AFSpecial_Keystroke and lets the user input anything they like.

I would recommend trying to fill the form with a non-English edition of Acrobat Reader, and see if the behavior is any different. If it is, then we have some localization to do. If the non-English Acrobat Reader also expects a US-based phone number, then this is a WontFix.

Thanks. The spec is quite vague on this matter

http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/FormsAPIReference.pdf

I just says "phone". So it seems to me that you have leeway to provide a
better user experience that Acrobat. Whatever about the formatting, not
being able to enter more than 10 digits or a + seems like an outright bug,
regardless of whether it's the same as Acrobat. I will try it with Japanese
Acrobat later but the idea that if my locale is en_us I should only be able
to enter US numbers also seems wrong to me.

Ideally, we would spot the + or the 00 and validate/format the number based
on country rules (using e.g. https://github.com/googlei18n/libphonenumber).

Sending over to dsinclair, since it sounds like this is more a defect in the PDF format then a Chrome/PDFium specific bug. We should actively choose if we are sticking with the Adobe behaviour or doing something else.

The spec says:

psf is the type of formatting to use:
 0 = zip code
 1 = zip + 4
 2 = phone
 3 = SSN

These were clearly conceived to be US identifiers by context (zip + 4 doesn't mean anything in the rest of the world, and SSN is US-only), but it is an inference and it wouldn't be incorrect to make the field more tolerant.

I agree with fergal@, we should leave the format open, and, if there is more time, validate it with an i18n library.

Mac triage: dsinclair@ or hnakashima@, what should we do with this bug?

The question becomes, if we relax the format will we break peoples handling of the submitted data? If this is expected to be US only, what happens when we send through other formats?

Passing to hnakashima@ for process for PE.

mac triage: marking assigned to hnakashima@.