まだ変換中なのに発火するEnterキー

検索ボックスにきょうと打って、スペースで今日に変換して、Enterで漢字を確定する。多くのサイトではその瞬間に検索が走る。きょうで、あるいは空で、あるいはフォームごと送信される。こっちは単語を選びたかっただけなのに、ページは「実行」と聞き取っている。

英語しか打たない人は、これを絶対に再現できない。変換という行為をしないからだ。だからこそ世に出てしまう。ハンドラを書いた本人はEnterを千回押して、その全部が送信を意味していた。

# 確定のEnterと、待ち受けているEnterは同じ

IMEはキー入力を候補の文字列に変えて、確定を待つ。確定のキーはたいていEnter。厄介なのは、そのEnterをkeydownのリスナーも見ていて、既定では「この変換を確定しろ」と「フォームを送信しろ」を区別できないこと。

ただ、ブラウザは手がかりを残してくれている。変換中のあいだ、keydownはisComposing === trueを持つし、もっと遡ると本当のキーの代わりにkeyCode === 229を返す。変換を閉じるEnterは、この変換中のkeydownだ。本当に欲しいEnter、単語が落ち着いた後のEnterは、そうじゃない。

# 直し方はガード一行

変換が進行中のあいだはハンドラを抜ける。

input.addEventListener("keydown", (e) => {
  if (e.isComposing || e.keyCode === 229) return; // まだ変換中
  if (e.key === "Enter") submit();
});

isComposingが今風の読みやすいチェック。keyCode === 229はそれをセットしないほど古いブラウザを拾う。両方残しても損は無いし、二つ目には素のAndroid WebViewで何度か助けられている。

# Reactはこのフラグを一段下に隠す

ReactはDOMイベントを包んでいて、合成イベントの側ではisComposingが当てにならない。欲しい値はネイティブイベントに乗っている。

- onKeyDown={(e) => { if (e.key === "Enter") search(); }}
+ onKeyDown={(e) => {
+   if (e.nativeEvent.isComposing) return;
+   if (e.key === "Enter") search();
+ }}

同じバグ、同じ一行の直し。nativeEvent越しに取りにいくだけ。僕がほとんどのコードベースに貼るのはこの版だ。大半がReactで、大半がe.isComposingを見て、undefinedを見つけて、静かに何もしていないから。

# 変換状態を自分で持つ

他の挙動も変換中だけ切り替えたい、みたいに状態を明示的に持ちたいなら、イベントはcompositionstartとcompositionend。

let composing = false;
el.addEventListener("compositionstart", () => (composing = true));
el.addEventListener("compositionend", () => (composing = false));
el.addEventListener("keydown", (e) => {
  if (composing) return;
  if (e.key === "Enter") submit();
});

# どこで止まるか

フラグ方式には知っておくべき鋭い角が一つある。最後の二つのイベントの順序が、ブラウザ間で一致しない。ものによってはcompositionendが確定のkeydownより先に発火するので、composingフラグはもうfalseになっていて、Enterが送信としてすり抜ける。直そうとしていた当のバグだ。だから僕はイベント単位のisComposing / keyCode 229チェックを先に置く。同期し続けないといけないフラグではなく、そのキー入力自体の状態を読むからだ。

そして正直な限界。これはフォームが日本語で動くことを証明しない。この一回のキー入力が動くことを証明するだけ。残りが保つかを知る唯一の方法は、実際に日本語を打ち込んでみること。それは、日本語を打たない人が書いたテストには永遠に現れない。