もずはっく日記(2014年6月)

Bug-org 1015028 Should compute scancode from virtual keycode at computing KeyboardEvent.code value if the key message doesn't have proper scancode
初回投稿日時: 2014年06月10日03時17分42秒
カテゴリ: Events Mozilla Core Mozilla32 Windows バグ修正
SNS: Tweet (list)

KeyboardEvent.codeは、Windowsでは、スキャンコードから求めていますが、::SendInput() APIから参照できる、KEYBDINPUT構造体のドキュメントを見る限り、各種ツール類が生成する疑似キーイベントには、適切なスキャンコードが設定されていない可能性が高いです。

幸い、Windowsでは、仮想キーコードから、現在選択されているキーボードレイアウトからスキャンコードを算出するAPIとして、::MapVirtualKeyEx()が存在していますので、スキャンコードがゼロの場合に限り、仮想キーコードから、スキャンコードを推測するようにしています。

ただし、この手法にも若干問題があり、0x00から0xFFで表現できない拡張キーと、拡張キーではないキーの両方で、その仮想キーコードが生成できる場合、上記のAPIは、拡張キーではない方のスキャンコードを返して来ます。ただ、これがやや期待とは異なる動作を行います。

拡張キーとは何か、ということがまずは重要ですが、一般的なキーボードで、Windowsが拡張キーとしているのは、矢印キー(ArrowDown、ArrowLeft、ArrowRight、ArrowUp)や、カーソル移動、編集に用いられるコントロールパッドにある、Insert、Delete、Home、End、PageDown、PageUp等があります。これらのキーは、テンキーのNumLockを解除している時に、同じ働きをしますが、テンキーの方は、非拡張キーにあたります。

このため、例えば、VK_DOWNの場合、算出されるスキャンコードは、テンキーの↓になり、その結果、.code値は、Numpad2になってしまいます。おそらく、多くのWeb開発者はArrowDownを期待すると思います。私もパッチをテストしている時に、そう期待しました。

現在のところ、この問題は、キーイベントを擬似的に生成するアプリのバグに起因する問題ですので、素直にAPIの算出結果に従うようにしています。

今後、DOMイベントがより、原始的な情報を提供できるようになればなるほど、Webアプリ開発時に、様々なブラウザ外の環境のバグも開発中のアプリに影響がでるようになっていく、ということに注意を払わなくてはいけなくなっていくことでしょう。