もずはっく日記(2018年12月)

Bug-org 1479964 Tracking event.keyCode issue due to the implementation of window.event
初回投稿日時: 2018年12月11日23時53分08秒
カテゴリ: Events KeyboardEvent Mozilla Core Mozilla65 バグ修正
SNS: Tweet (list)

多くのデキの悪いサイトがGeckoで動かない原因のひとつに、イベントリスナにeventという引数を渡していないのに、event.preventDefault()等と書き、実質的にwindow.eventを参照しているというケースが多々あったそうです。これに対する互換性としてwindow.eventはWHATWGによって標準仕様に取り込まれることになったので、Geckoでもサポートするようにした模様です。

ところが、いざ実際にこれを実装し、有効化してみると、多くのサイトがwindow.eventをIEと同じkeypressイベントが来るかどうかを判定するfeature detectionとしてこれを参照していました。当然、これらに関連性は皆無なので、そのように書かれていると動きません。まさにそのようなアプリのコードはfeature detectionの悪い例です。

そこで急遽、keypressイベントのみ、KeyboardEvent.keyCodeとKeyboardEvent.charCodeの値をどちらか非ゼロの値をもう一方にセットしなくてはいけなくなりました。

Geckoでは、keypressイベントのKeyboardEvent.keyCodeの値をまずは先行するkeydownイベントと同じものと仮セットします。次に、KeyboardEvent.charCodeをそのキー入力、もしくは、そのキー入力からCtrl、Alt、またはCommandの状態を取り除いた際に入力される文字のUnicodeコードポイントにセットします。最後に、KeyboardEvent.charCode値が非ゼロ場合、KeyboardEvent.keyCodeをゼロにしていました。

しかし、他のブラウザでは最後の段階でKeyboardEvent.keyCodeにKeyboardEvent.charCodeの値をセットし、逆に、KeyboardEvent.charCodeの値がゼロの場合(Enterキーの場合)にKeyboardEvent.keyCodeの値をKeyboardEvent.charCodeにセットしていました。

幸いにもnon-printableキーのkeypressイベントの発火を止める修正が進行中だったので、少ないリスクでこの修正を行うことができました。

それにしても、本当に、論理的に考えずにトライアンドエラーだけで実装しちゃう人が多いんですね。一見関連性のあるもの同士を対にしていたために壊れるサイトが多かったことに非常に驚かされました。