What's your Chrome UI language?  I think Arabic digits are accepted if Chrome UI language is Arabic.

No. I changed the Chrome UI language to Arabic and they're still not accepted.

Actually, I think they should be accepted regardless of the browser or OS language. Many users are bilingual and may prefer to have the UI in English, and at the same time fill a form while the keyboard is set to another language.

Thank you for providing feedback. removing "Needs-Feedback" label.

Able to reproduce the issue on the latest canary(58.0.3028.0/58.0.3027.3) and the latest stable(56.0.2924.87) on Windows-10, Mac OS 10.12.3 and Linux Ubuntu 14.04. Changing the Chrome UI language to arabic also doesn't accept the copied text. 

Regressed in M-44.

Last good build: 44.0.2378.0
First bad build: 44.0.2379.0

Changelog: https://chromium.googlesource.com/chromium/src/+log/581222c25bb9b1c435be50bb9d434bef564f02c5..11e724cae6142ebb800a796fc8d4d36f0aa55c68

Blink changelog: https://chromium.googlesource.com/chromium/blink/+log/869bde4..40dd7d5

Suspecting: https://codereview.chromium.org/1100273002

tkent@: Could you please take a look at this.

Thank you!

I still can't reproduce this.

With chrome in Arabic (chrome.exe --lang=ar), the following URL shows "١٠٢٤" expectedly, and I can paste Arabic digits into the number field.  I don't know how to type them with a keyboard.

data:text/html,<input type="number" value="1024">

imgx64@, does <input type=number value=1024> show Arabic digits in your environment?

Oddly enough, yes, it shows Arabic digits, and it even accepts them as input. But it's still buggy.

For some reason, if `value` is not set, it doesn't work. But if you set the value (with HTML or programatically) to *any* `number` input in the page, all the number inputs in the tab start to accept Arabic digits. And they keep working even if you go to another page, until you close that tab. That's definitely a bug.

However, that only works when the Chrome UI language is Arabic. As I've explained above in Comment 2, they should be always accepted regardless of UI language. In our experience, most bilingual users have the UI in English and only switch the keyboard language when needed.

Aha, I understand the root cause of the issue.  We miss to initialize localized digits data while keyboard input processing though it is initialized while showing localized digits.

I'll fix this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/627d462e4a1fb99efa5d66caf6648a5cb246ffa6

commit 627d462e4a1fb99efa5d66caf6648a5cb246ffa6
Author: tkent <tkent@chromium.org>
Date: Tue Mar 07 23:28:46 2017

<input type=number>: accept localized digits without showing them.

Locale::stripInvalidNumberCharacters() missed to call initializeLocaleData().

BUG= 694391 

Review-Url: https://codereview.chromium.org/2738463003
Cr-Commit-Position: refs/heads/master@{#455286}

[modify] https://crrev.com/627d462e4a1fb99efa5d66caf6648a5cb246ffa6/third_party/WebKit/Source/platform/BUILD.gn
[modify] https://crrev.com/627d462e4a1fb99efa5d66caf6648a5cb246ffa6/third_party/WebKit/Source/platform/text/PlatformLocale.cpp
[modify] https://crrev.com/627d462e4a1fb99efa5d66caf6648a5cb246ffa6/third_party/WebKit/Source/platform/text/PlatformLocale.h
[add] https://crrev.com/627d462e4a1fb99efa5d66caf6648a5cb246ffa6/third_party/WebKit/Source/platform/text/PlatformLocaleTest.cpp

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), bhthompson@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@tkent , this fix only applies when Chrome's UI language is Arabic, which is a secondary bug and is *not* the issue reported here.

This issue is about making non-latin digits work regardless of UI language. The original bug report did not mention the UI language at all because it didn't seem important. After all, in a number context, "٤" has no meaning other than "4", so there's no reason to disallow it.

We actually have users who complained that they couldn't type in some input fields. Their UI language is English, their keyboard language is Arabic and they were trying to type into an <input type="number"> on an Arabic page. What do you suggest we do in this case? We ended up using <input type="tel"> and converting the digits in JavaScript, which just feels like a hack.

Is such fix worth implementing or do you think it's a WontFix? If you think it's undesirable, can it at least be implemented when the page has <html lang="ar"> or something?

We don't have a plan to change the current design.
However, we'd like to make form controls lang-attribute-aware.  It's Issue 141169.

Please merge your change to M58 branch 3029 before 5:00 PM PT, Monday (03/13/17) so we can take it in for next week dev release. Thank you!

Merged to M58.
https://chromium.googlesource.com/chromium/src/+/bf33f15f9b05b7d407347b2a17f91c430dbab35f

Verified the fix on the latest M-58(58.0.3029.19) on Windows-10,Mac OS 10.12.3 and Linux Ubuntu 14.04. Able to paste the content into the text box as per the attached test file(numbers.html). Works only when the Chrome UI language is Arabic.

Adding the verified label.