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

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

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

2014年10月30日

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: (list)

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

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

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

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

nsIDOMWindowUtils.sendCompositionEvent()に、compositionupdateを渡しても、このメソッドは何もしないように変更されています(互換性のため、例外も発生しません)。nsICompositionStringSynthesizer.dispatchEvent()を呼び出すと、未確定文字列の変更が発生した場合にのみ、自動的にcompositionupdateイベントも発火されます。

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

bug-org 975383を含むエントリ

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

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