この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

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

2011年12月26日

Bug-org 713502 input event should be fired after compositionupdate
初回投稿日時: 2011年12月26日18時00分11秒
最終更新日時: 2011年12月26日22時36分20秒
カテゴリ: Mozilla Core バグ報告 バグ検証中
SNS: (list)

この年の瀬に超ブルーなバグを見つけてしまいました。

compositionupdateの送信タイミングに問題があるんですが、GeckoとWebKitはエディタで実際に処理が発生する前にイベントを発行します。それに対して、IEは編集が実際に終わった後に発行されます。

これがどのような違いを産むかというと、そのエディタのコンテンツをcompositionupdateイベントハンドラで取得した場合に違いがでます。GeckoとWebKitでは新しい未確定文字列が反映される前の値が、IEでは新しい未確定文字列が反映された値が取得できます。

ではWebKitではGeckoと同様に最新の未確定文字列を取る方法が無いのかと言うとそういうわけではありません。昔からあるinputイベントがcompositionupdateの直後にやってきます。そして、このイベントのハンドラからエディタにアクセスすると、最新の未確定文字列が反映された値がとれます。

ちなみにIEではinputイベントがcompositionupdateの直前に発行されますが、やはり反映済みの最新の値をとることができます。

Web開発者からすれば少なくともinputイベントでこれらのブラウザで同じように処理できるようになっていることが望ましいでしょう。実際にこの動作の修正は一行修正するだけでGeckoもWebKitと同様に動作するようになります。

しかし話がここで終わりません。

まだ調査中ですが、XULでinputイベントをハンドリングしているコードがそれなりの数あるようです。また、それらのコードは結構な割合でUIになんらかのフィードバックを行っているので、これが未確定文字列の強制確定の原因になる可能性があります。この問題は当然放置できないので全てなんらかの手段で修正、もしくは回避しなくてはいけませんが、中々に頭の痛い問題です。

inputイベントのハンドラで、分かるもので調べてみましたが、特に問題なさそうです。予想外なのが非常に気持ち悪いんですが……

関連するかもしれないエントリ

bug-org 713502を含むエントリ

Bug-org 713502 input event should be fired after compositionupdate #2

このエントリへのリンク元