Bug-org 1200980 [e10s][TSF] Candidate window is sometimes not positioned properly because IMEContentObserver sometimes fails to notify IME of selection change
初回投稿日時: 2015年09月17日21時39分08秒
カテゴリ: e10s Events IME Mozilla Core Mozilla43 TSF Windows バグ修正
SNS:
Tweet (list)
twitter.comでリプライを入力する時にATOKのナビバーや、様々なTIPのサジェストウインドウや、候補ウインドウがキャレット位置等の適当な位置に表示されないというバグです。
調査してみると、ContentCacheInChild
がNOTIFY_IME_OF_POSITION_CHANGE
を受け取ってWidgetQueryContentEvent
を利用してコンテンツの情報を取得し、キャッシュする際に選択範囲がおかしな値になっていることがあることが分かりました。その原因は今でも分かっていませんが、NOTIFY_IME_OF_POSITION_CHANGE
を通知してはいけないタイミングが未だに存在し、ContentEventHandler
がフォーカスを持ったcontenteditable
なエディタだけではなく、ドキュメント全体をターゲットにしてコンテンツを取得して値がおかしくなっているようでした。
根本的な原因の調査にはものすごく時間がかかることが明らかなので、無理の無いアプローチでバグを隠してしまうことにしました。まず、WidgetQueryContentEvent
をContentEventHandler
に渡す場所を変更しました。エディタがフォーカスを持たない場合は今まで通りEventStateManager::PreHandleEvent()
から処理しますが、IMEContentObserver
のインスタンスが存在する場合はIMEContentObserver
経由で呼び出すようにしました。
これにより、WidgetQueryContentEvent
の戻り値の値をキャッシュし、適切な時に破棄することが可能になります。今回の場合、選択範囲を正しく返すことができればひとまずバグを隠すことができるので、NS_QUERY_SELECTED_TEXT
に対しては常にキャッシュしてある情報を返すようにしました。これにより、安全なタイミングでキャッシュされた正しい選択範囲の情報が常にTIPに渡るようになっています。
なお、このバグの調査のために書いたIMECntentObserver
のロギングコードはそのまま投入されていますので、NSPR_LOG_MODULES=IMEContentObserver:5
でIME (widget)への通知の発行部分をログから調査できるようになっています。
また、IMEContentObserver::EditAction()
が適切に呼び出されないバグも発見したため、修正していますが、これの副作用により、input
イベントの発火仕様が若干変更されています。未確定文字列が空になった時にはinput
イベントが発火されていませんでした。これは、未確定文字列になった時には直後にcompositionend
が来て、その後にinput
イベントが確実に発火されるという前提に基づいたものでしたが、compositionend
を伴わないケースではinput
イベントが発火するようになっています。この変更は実際にはどのIMEを利用していてもおそらく実際には発生しない差異だとは思います(知る限り、そのような動作をしたIMEを知らない)。