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

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

もずはっく日記(2016年1月)

2016年1月30日

Bug-org 1243657 [IMM] When there is only composition string in editor, canceling the composition causes painting caret at odd position (right-most of the editor)
初回投稿日時: 2016年01月30日23時51分05秒
カテゴリ: IME Mozilla Core Mozilla47 Windows バグ修正
SNS: (list)

空の<input>要素でスペルチェッカを有効にし、未確定文字列を入力、それをキャンセルすると、<input>要素の右端にキャレットが表示されてしまうというバグで、何故か、WindowsではIMMモードでは再現が確認されているものの、TSFモードでは再現が確認できない不思議なバグです。

デバッグビルドで走らせてみると、エディタとスペルチェッカで、警告をいくつか吐いていました。その内容から、編集直後にスペルチェッカがスペルチェックを行おうとして失敗したあと、空のエディタに必要な匿名の<br>要素の生成が行われてないことが分かりました。

直接、エラーを返しているのは、編集前にキャレットがあったノードと、現在の選択範囲を比較するRange::Compare()でした。IMEの未確定文字列は削除されてエディタは空になっているので、その編集前にキャレットがあったノードというのは既にドキュメントから削除されています。ですので、比較に失敗するのは自明なわけです。

その直前の処理を見ると、エディタの変更理由が削除だった場合は比較を行わずにその処理を終了していました。とすると、ここにIMEの未確定文字列の変更の場合でも、未確定文字列が空になった場合には削除と同じ扱いで処理してもらわなくてはいけないことが分かります。しかし、そのメソッドでは未確定文字列がどうなったのかは分かりません。そこで代わりに、比較対象のノードがドキュメントから削除されている場合には、通常の削除処理と同じように処理するように修正しました。

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

bug-org 1243657を含むエントリ