Produced by Fourier

ChromiumとWebKitにコントリビュートした備忘録

Kyouhei Horizumi icon Kyouhei Horizumi

どのような問題点があったか

日本語入力環境では「全角数字（１２３４…）」を入力するケースが多く存在します。ところが、 <input type="number"> は仕様上「半角数字のみ」を受け付ける設計となっており、主要ブラウザの実装でも全角数字は「非数値」と判断され、入力が拒否されてしまいます。

この挙動は、ユーザーと開発者の両方に大きな問題を引き起こしていました。

  • ユーザー体験の問題

    日本のユーザーは日常的に全角数字を使うため、入力途中で弾かれてしまい、フォームが使いにくい状況が発生します。

  • 開発者体験の問題

    仕様やブラウザの制約を回避するため、開発者はやむを得ず type="text" を使い、数値チェックやバリデーション、UI改善を自前で実装しなければならないケースが多発しました。

結果として、フォームの入力体験が不自然になり、さらに余計な実装コストが発生するという二重の課題が存在していました。

何を修正したか

問題の根本は、ブラウザが全角数字を「数値」と認識しないことにありました。これに対し、 Unicodeの [全角数字 (U+FF10–U+FF19)] を半角に正規化してから内部処理へ渡す 、というシンプルなアプローチを採用しました。これにより、ユーザーが自然に入力する全角数字も、ブラウザ内部では正しく数値として扱われるようになります。

実装面での対応

  • Blink (Chromium)

    chromium-review.googlesource.com にて修正を行いました。

    input[type=number] の入力処理を変更し、全角数字や一部記号を半角へ正規化したうえで内部に渡すようにしています。

  • WebKit

    WebKitのコミット でも同様の修正を行いました。

    こちらも入力時に正規化を行い、全角数字を受け入れられるようにしています。

テストの追加

ブラウザ実装の信頼性を担保するため、各エンジンにテストも加えました。

  • Blink

    UnitTestを追加し、入力値の正規化が正しく機能するかを検証しています。

  • WebKit

    LayoutTestsを追加し、実際のブラウザ挙動を通じて、全角数字が正常に入力できることを確認しています。

OSSのコントリビュートまでの流れ

今回の修正は、単にコードを書くだけではなく、仕様や他ブラウザの挙動を踏まえた上で、各ブラウザエンジンに提案・実装するプロセスを経ました。以下が大まかな流れです。

調査

まず WHATWG の Issue を確認し、仕様上どのように扱われるべきかを把握しました。そのうえで主要ブラウザで挙動を比較しました。

  • Firefox : 全角数字でも入力可能
  • Chrome : 全角数字を入力すると、確定した瞬間に消えてしまう
  • Safari : 視覚的には入力されるが、内部的には数値として扱われていない

この調査により、ブラウザ間で大きな差があることが明らかになりました。

では逆にFirefoxがHTML仕様違反を犯している可能性があるので、仕様書を確認しました。 すると入力値のUIはHTML仕様の範囲ではないことが分かりました。

結果HTML仕様書の問題ではないことが分かったので、とりあえず同じようなIssueがないことを確認し、各ブラウザにIssueを投げることにしました。

報告

調査結果をもとに、各ブラウザプロジェクトへ正式に報告しました。

実装

2024年の12月頃にIssueを提出したのですが、半年経っても中々修正される気配がなさそうでした。

個人的に他の国のキーボード事情ってあまり考える機会がないと思うので、この問題はそもそも日本人が対応すべき話なのかなと思い、コード修正にも着手しました。

  • 該当リポジトリ（Chromium: chromium/src , WebKit: webkit/WebKit ）を clone
  • ビルド環境を整備（初回は非常に時間がかかる）
  • 修正を加え、ローカルで挙動を確認

レビュー

修正が完成したら Pull Request を送信し、各プロジェクトのメンテナやレビューアからのフィードバックを受けながらブラッシュアップしました。

フィードバックとしては、変数名や変数の位置とかクラスの使い方とかでしょうか。 最終的に承認され、コードがマージされることで修正が正式に取り込まれました。

💡
Chromiumは、レビュワー二人の承認が必要です

Chromiumの修正について

Chromiumへのコントリビュートは、周辺知識を持っていないと環境構築やワークフローで詰まりやすい部分があります。Jxck氏のブログが非常に参考になったので、これから挑戦する方には以下の記事を強くおすすめします。

WebKitの修正について

WebKitに関しては、macOS 上で開発を行いました。（Windowsでの開発はかなり難しいと思われます）

WebKitは GitHub 上で管理されており、通常の OSS と同様に clone して修正を加え、Pull Request を送ればコントリビュート可能です。

💡
Tools/Scripts/ 以下に、ビルドやテストに関する便利スクリプトが多数用意されています。
⚠️
Chromiumと似たコードも一部ありますが、開発方針や命名規則が異なるため、細部まで注意する必要があります。

ビルド方法

基本的には以下のコマンドでビルドを実行しました。 

Tools/Scripts/build-webkit --debug

参考: Building Options - WebKit Documentation

スタイル修正

WebKitでは、コードを整形するスクリプトが用意されているため、修正後は以下を利用しました。 

Tools/Scripts/check-webkit-style

ビルド後の確認（ミニブラウザ起動）

動作確認には、ミニブラウザを起動してテストしました。 

Tools/Scripts/run-minibrowser --debug
💡
私の環境だけかもしれませんが、「 ⌘英かな 」を有効にした状態で Command キーを押すとブラウザがクラッシュしました。注意が必要です。

テストの実行

修正が意図通り動作するか確認するため、テストも実行しました。 

Tools/Scripts/run-webkit-tests --debug fast/dom/<テストHTMLファイル名>

参考: Testing - WebKit Documentation

提出について

WebKit にはコントリビュート用のコマンドやガイドラインが整備されています。これを活用することで、スムーズに Pull Request を提出できます。

参考: Getting Started Contributing - WebKit Documentation

まとめ

今回の修正は、日本のユーザーにとって大きなUX改善につながっただけでなく、仕様面とOSS実装の両方に貢献できた意義深い取り組みでした。

OSS へのコントリビュートは一見するとハードルが高く感じられます。しかし、調査・報告・実装・レビューと手順を踏めば、誰でも参加できる道が開かれています。実際にコードがマージされ、世界中のユーザー体験を改善できるのは非常に大きな達成感があります。

気になったのは、日本特有の部分はそもそも報告が少ないし実装できる人も少ないように思えました。自国のことは、できる人がどんどんやれば良いと思います。

今後もブラウザの国際化や、より多くのユーザーが自然に使える体験の実現に向けて、継続的に貢献していきたいと考えています。

今やっていること・読者様へお願い

現在は WHATWG HTML 仕様そのものに対して Pull Request を送っています。

Define optional normalization of full-width characters in <input type="number"> · Issue #11395 · whatwg/html thumbnail
Define optional normalization of full-width characters in <input type="number"> · Issue #11395 · whatwg/html

What is the issue with the HTML Standard? Problem Statement In Japanese input environments, users frequently type full-width digits and symbols using IMEs when entering numbers. However, because <i...

https://github.com/whatwg/html/issues/11395

この PR では、 <input type="number"> のユーザー入力に対して UI レベルでの事前正規化 を推奨（SHOULD）する文言を仕様に追加し、CJK 環境で利用される全角数字や一部記号を明示的に受け入れる提案をしています。

提案内容（概要）

  • 対象文字の列挙（CJK全角文脈）
    • U+FF10–U+FF19（全角数字）
    • U+FF0D（全角ハイフンマイナス）
    • U+2212（数学記号マイナス）
    • U+30FC（長音記号）
    • U+FF0E（全角ピリオド）
  • 設計上のポイント
    • 値の内部表現（wire format）は引き続き ASCII ベースでロケール非依存とする
    • .value などスクリプト代入は正規化対象外（ユーザー入力のみ）

特に意見募集

  • 許可する文字集合の範囲
    • 特に「U+30FC 長音記号」を含めるかどうか
      • 日本語 IME が有効な状態でハイフンキーを押すと、 長音記号（U+30FC） が入力される挙動があります。そのため、数値入力フィールドで誤って弾かれないよう、この文字を受け入れ候補に加えました。
    • 現状の列挙を維持するか、位置制限（例: 符号のみ）を加えるか、それとも後続ステップで拡張するか

現在、この点について広くフィードバックを募っています。日本語入力環境の立場からも 「追加すべき記号があるか」「提案に賛同できるか」「懸念があるか」 など、ぜひ意見をいただけると助かります。

X(Twitter) Facebook
Kyouhei Horizumi icon

関連記事