Bug 284363 – <input type="number"> does not support full-width numbers (e.g., "ー２００") for Japanese IME users

• Component: Forms
• Status: RESOLVED FIXED

[Kyouhei Horizumi]

When entering full-width numbers in an `<input type="number">` field and pressing Enter, the entered value disappears.
Unlike Firefox, Webkit-based browsers do not support full-width number input. This results in complaints from some Japanese users, especially those unfamiliar with input limitations, as they are unable to input numbers.
Safari should allow full-width number input, similar to Firefox.

## Reproduction Steps:

1. Create an `<input type="number">` field.
2. Try entering the value `ー２００` (a full-width number).

## Expected Behavior:

The browser should accept full-width numbers as valid input and convert them to their half-width equivalents when necessary, similar to Firefox.

## Actual Behavior:

### Safari:
Input value: ー２００ (input allowed, but invalid)  
.value: "" 
.valueAsNumber: NaN  

### Firefox:
Input value: ー２００ (input allowed, valid)    
.value: "-200"  
.valueAsNumber: -200  

### Chrome:
Input value: ー２００ (unable to input)  
.value: ""  
.valueAsNumber: NaN

## Environment:

+ Safari Technology Preview Release 209 (Safari 18.2, Webkit 20621.1.6) (macOS 15)
+ Firefox 133.0 (Windows 11)
+ Chrome 131.0.6778.109 (Windows 11)

## Reference

https://issuetracker.google.com/issues/383232110

[Radar WebKit Bug Importer]

<rdar://problem/141257181>

[Kyouhei Horizumi]

Sorry,
I initially wrote that when entering full-width numbers in an <input type="number"> field and pressing Enter, the entered value disappears. 
However, I need to correct this: that behavior occurs in Chrome.
In WebKit, the value does not disappear when pressing Enter but is internally treated as empty.

[Karl Dubost]

Created attachment 473601 [details]
testcase

This is a testcase to quickly try the issue for someone.

[Anne van Kesteren]

See also bug 250535. We're generally pretty strict at the moment for end user input, which isn't ideal.

[Kyouhei Horizumi]

Created attachment 475624 [details]
Japanese Full-width Input Normalization Test

Replacing the previous test with a complete, self-contained test case for <input type="number"> normalization.

This test covers:
- Full-width digits (U+FF10–U+FF19)
- Minus sign variants:
  - U+FF0D (full-width hyphen-minus, common on Windows)
  - U+30FC (long sound mark, inserted by IMEs when typing minus in kana mode)
  - U+2212 (Unicode minus sign, common on macOS)
- Full-width full stop (U+FF0E)

[Kyouhei Horizumi]

Created attachment 475626 [details]
Patch

[Karl Dubost]

are there tests for web platform tests? 

Maybe some additional tests to add to 
https://wpt.fyi/results/html/semantics/forms/the-input-element

[Kyouhei Horizumi]

For now, I’ve only added a LayoutTests. I’ll look into adding a WPT later.

[Kyouhei Horizumi]

(In reply to Karl Dubost from comment #7)
> are there tests for web platform tests? 
> 
> Maybe some additional tests to add to 
> https://wpt.fyi/results/html/semantics/forms/the-input-element

As far as I understand, there is a patch under review in WebKit that normalizes full-width characters entered into <input type="number"> fields:

- Full-width digits: U+FF10–U+FF19
- Minus variants:
  - U+30FC (long sound mark)
  - U+FF0D (full-width hyphen-minus, often from Windows)
  - U+2212 (Unicode minus sign, often from macOS)
- Full-width full stop: U+FF0E

These characters are mapped to their ASCII equivalents during native text input — not via JavaScript assignment to `.value`.  
(Note that in WebKit and Firefox, assigning full-width characters to `.value` is accepted, while in Chromium it is not, since such behavior is currently outside the scope of the HTML specification.)

Since Web Platform Tests (WPT) are intended to cover only behaviors explicitly defined in the HTML specification, we cannot add corresponding WPTs unless this normalization is formally specified.


This raises a broader question:  
**Should this normalization be defined in the HTML specification, so that all engines behave consistently?**

At present, this is treated as an implementation detail within each engine's input handling layer. But from a user’s perspective — especially in Japanese input environments — numeric input is expected to “just work,” regardless of character variants.

Would you be open to discussing whether this behavior could be standardized (e.g., through parsing/sanitization rules or input behavior notes)?  
I'm happy to draft an issue on WHATWG if you think it would be appropriate.

[Alexey Proskuryakov]

Comment on attachment 475626 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=475626&action=review

> LayoutTests/fast/forms/number/number-fullwidth-numeral-normalization-expected.txt:7
> +        text run at (0,0) width 37: "PASS"

Given that this is a pass/fail test, having a render tree dump makes it more difficult to maintain (unnecessary dependency on font sizes). And definitely no need for a .png expectation here.

You can start with the `make-new-script-test` script to create a template, and then you can mostly copy/paste into it.

I do not have any opinions about the rest of the proposed patch.

[Kyouhei Horizumi]

(In reply to Alexey Proskuryakov from comment #10)
> Comment on attachment 475626 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=475626&action=review
> 
> > LayoutTests/fast/forms/number/number-fullwidth-numeral-normalization-expected.txt:7
> > +        text run at (0,0) width 37: "PASS"
> 
> Given that this is a pass/fail test, having a render tree dump makes it more
> difficult to maintain (unnecessary dependency on font sizes). And definitely
> no need for a .png expectation here.
> 
> You can start with the `make-new-script-test` script to create a template,
> and then you can mostly copy/paste into it.
> 
> I do not have any opinions about the rest of the proposed patch.

Thank you for the review.
I'll follow your suggestion and create the test using make-new-script-test as a pass/fail test without relying on render tree dumps or PNG expectations.

Also, since it's more common nowadays, I'll prepare a revised version as a GitHub Pull Request rather than a patch file.

[Kyouhei Horizumi]

Pull request: https://github.com/WebKit/WebKit/pull/47095

[Kyouhei Horizumi]

Created attachment 475644 [details]
Japanese Full-width Input Normalization Testcase

[Kyouhei Horizumi]

Created attachment 475645 [details]
Japanese Full-width Input Normalization Testcase

[EWS]

Committed 298613@main (6c84234e57fc): <https://commits.webkit.org/298613@main>

Reviewed commits have been landed. Closing PR #47095 and removing active labels.