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

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

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

2014年11月21日

Bug-org 1047588 Intermittent 456727-2.html,test_bug611182.html | application crashed [@ mozilla::IMEContentObserver::Init(nsIWidget*, nsPresContext*, nsIContent*)] after "Assertion failure: mEditor (Failed to get editor), at dom/events/IMEContentObserver.cpp:127"
初回投稿日時: 2014年11月21日16時17分44秒
最終更新日時: 2014年11月21日16時18分14秒
カテゴリ: Mozilla Core Mozilla35 Mozilla36 バグ修正
SNS: (list)

Bug-org 496360の修正によるregressionというか、その修正自体のバグです。Bug-org 496360の修正で、IMEContentObserverは、エディタの編集アクション一回につき、一回だけ通知を発行することで、パフォーマンスを向上させていますが、このためには当然、フォーカスを持ったエディタの取得が必要になります。デバッグビルドでは、エディタの取得に意図せず失敗した場合に、クラッシュするようにしていましたので、これにより、レアケースのバグが自動テストであぶり出された形になります。

ちなみに、リリースビルドではパフォーマンスが従来通り悪いまま、クラッシュせずに動作するようになっていたので、実際のユーザがこれによってデータロス等を経験はしている可能性はあまりないと思います(このレアケースにはまった時に、膨大な量のテキストを貼り付けるとしばらくの間ハングアップするので、その間に強制終了するとなんらかのデータロスが発生している可能性はありますが)。

とにかく発生頻度が低く、1日中テストしてても、2回ぐらいしか再現しないので、原因の特定にすごい日数かかりましたが、結局、どのようにしてその状況に陥るのかは最後まで分からずじまいでした。とりあえず、判明したのは、designModeonに設定した時、なぜか、エディタがフォーカスを取得した時点で、documentは編集可能と状態更新済みなのに、nsDocShellに編集可能になったことの通知とnsHTMLEditorへのポインタの受け渡しが終わっていない、という状況が発生しうるということでした。

これにより、IMEStateManager::GetRootEditableNode()は編集可能と期待通りの結果を返すのに対し、nsContentUtils::GetHTMLEditor()はまだnsDocShellnsHTMLEditorが登録されていないので、nullptrを返してしまうことが分かりました。

今回の修正では、問題のコードが呼び出される時は、必ずnsEditorEventListener::Focus()がスタックに含まれているので、この時経由する全てのメソッドにエディタへのポインタを引数で渡し、IMEContentObserver::Init()が確実にエディタへのポインタを利用できるようにしています。

比較的安全な修正かつ、このオレンジの頻度が比較的高いということで、Auroraでも修正されています。

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

bug-org 1047588を含むエントリ