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

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

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

2014年9月30日

Bug-org 1072137 Assertion failure: editingHost == mEditableNode (found editing host should be mEditableNode)
初回投稿日時: 2014年09月30日17時59分46秒
カテゴリ: Javascript Mozilla Core Mozilla35 バグ修正
SNS: (list)

documentのルートノードを、Javascriptを使って、<textarea>要素にし、さらに、その子要素に、<input type="text">要素を追加し、これにフォーカスをあわせると、デバッグビルドでは異常を検知して、IMEContentObserver内でクラッシュする、というバグです。

検知した異常というのは、フォーカスノードから算出した、編集可能なルートノードと、そのエディタが一致しない、というものでした。

IMEContentObserver::Init()内でIMEStateManager::GetRootEditableNode()を呼び出し、フォーカスノードの親が編集可能なら、さらに祖先が編集可能か調査し、編集可能な最後の祖先を探します。これにより、IMEContentObserver::Init()はこのケースでは<input type="text">要素が欲しかったのですが、<textarea>要素が返され、さらに、このような異常な状況下では、<textarea>要素は自身のエディタを生成していませんでした。

これだけなら、非常にマイナーかつ、実際には起こりえないようなバグですが、このバグの原因からすると、<body contenteditable><input type="text"></body>の様な場合にも、<input type="text">要素がフォーカスを持っていても、算出される編集可能なルート要素は、<body>要素、ということになります。

そのため、IMEContentObserverはこのようなケースでは、誤った要素を監視していることになり、これはデリケートなTSFモードでは色々と嫌なシナリオが思い浮かびます。

ひとまず、このバグでは、要素を祖先方向に辿って、編集可能か調べていく際に、そのノードが独立したセレクションを管理しているかどうかを調査し、該当した場合にはそれをルート要素として返すように、IMEStateManager::GetRootEditableNode()を修正しました。

独立したセレクションは現在、<input><textarea><select>要素のみが持ち得ていて、<select>要素は常に編集不能と判定されるので、論理的にはまずい対応ですが、とりあえずは動く形になっています。

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

bug-org 1072137を含むエントリ

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

このエントリを参照しているURIはありません。