もずはっく日記(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:
Tweet (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>要素は常に編集不能と判定されるので、論理的にはまずい対応ですが、とりあえずは動く形になっています。