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

Bug-org 975383 Dispatch compositionupdate from TextComposition rather than widget
初回投稿日時: 2014年10月30日16時47分26秒
最終更新日時: 2014年10月30日17時20分18秒
カテゴリ: e10s Events Mozilla Core Mozilla35 バグ修正
SNS: Tweet (list)

現在、compositionupdateの内部イベントである、NS_COMPOSITION_UPDATEイベントは、各OS用のwidgetから発火していますが、同じロジックで発火している上、XPレベルでは、TextCompositionクラスで管理している未確定文字列の情報をwidget側と二重管理するのは勿体ないということで、NS_COMPOSITION_UPDATEを、TextCompositionで発火するようにしよう、というバグです。

この修正により、widgetが発火する内部イベントは、NS_COMPOSITION_START、NS_COMPOSITION_END、NS_TEXT_TEXTイベントの三種類のみになりました。TextCompositionイベントは、NS_TEXT_TEXTイベントが発火されると、PresShellから、IMEStateManager::DispatchCompositionEvent()経由で、DOMツリーにイベントを発火前に受け取り、この際に、未確定文字列に変化がある場合にのみ、NS_COMPOSITION_UPDATEイベントを発火するようになりました。

これにより、一部のwidgetでは未確定文字列を保存しておかなくてよくなりました。メモリ容量は未確定文字列の長さからして、問題にはなりませんが、メモリのフラグメンテーションについては多少、懸念が無くなりました。また、NS_COMPOSITION_UPDATEの発火後の各種オブジェクトの生存確認をXPレベルで確実に行えるので、安全性が高まっています。そして、XP化により、全てのプラットフォームで確実に同じ条件で発火するようになりました。今までは、Android版のみ、未確定文字列に変化がなくても、compositionupdateイベントが発火されていたように思います(実際には未確認)。

最後に、e10sモードでは、compositionupdateを発火するにあたり、widgetから発火して、子プロセスがフォーカスを持つ場合には、プロセス間通信が必要でしたが、これが不要になったため、未確定文字列操作時のパフォーマンスがかなり改善しています。