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

Bug-org 692145 Firefox Crash [@ nsTextFragment::CharAt(int) ]
初回投稿日時: 2012年01月31日17時19分04秒
最終更新日時: 2012年01月31日17時50分40秒
カテゴリ: Firefox Mozilla Core Mozilla12 Thunderbird バグ修正
SNS: Tweet (list)

週末に、クラッシュだけを抑えるパッチのレビュー依頼が来ていて、初めて気付いた重大なバグです。影響があるのはWindows版のFirefox 7から、Firefox 11までと、Firefox 10ベースでリリースされるESRです。現在のところ、Firefox 12には滑り込みで間に合いました。明日以降にドライバに連絡とってみますが、他のバージョンで修正が許可されるかは今のところ不明なバグです。

このバグは、bug-org 665858の修正のregressionです。Bug-org 665858は、IMEがキャレットの位置等を問い合わせて来た場合のパフォーマンスが、大きな内容を持つエディタ上では異様に遅くなる、というパフォーマンスに関するバグで、その原因は内容をプレーンテキスト化した時の長さを求める処理にありました。当初の実装では、コードのシンプルさのために問い合わせられた内容を実際にプレーンテキスト化してから改行コードの置換処理(\nから\r\n)を行い、文字列の長さを取得するというもので、この置換が遅かったのです。このため、この時の修正では実際にプレーンテキストを生成せずに改行文字の数をカウントして算出するという方法に変更されました。

ですが、このカウントするコードに問題があり、文字列のどの範囲でカウントするのか、という長さを指定するパラメータが、\n時の文字数で受け取ることを前提としているにも関わらず、呼び出し側がここに\r\n時の文字数を渡しているバグがありました。このため、行数が多い文章を書いている時に、エディタの最後で未確定文字列を入力すると、配列外の参照が発生し、希にクラッシュするということになっていました。

このバグによるおかしな挙動はクラッシュ以外にも簡単に見られます。例えば、エディタ上でEnterキーを押して、空の行を大量に入力してから、IMEで一文字だけ入力して変換してみてください。そうすると、未確定文字列と候補ウインドウが重なるという現象が見られることがあります。これは、実際の挿入位置よりも手前の行の座標を算出してしまっているために発生します。ただ、ATOKでは発生しづらく、MS-IMEの方が簡単に再現できます。これは、IMEが発行してくるメッセージの違いによるものだと思います(ATOK側がこちらのバグを踏みづらい状況にあっただけ)。

このバグに対してユーザがとれるワークアラウンドは、外部のエディタで書いて貼り付けるか、先に改行だけ大量に挿入しておいて、先頭の方で編集して、最後に不要な改行を削除する、といったかなり後ろ向きな手段しかありません。