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

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

もずはっく日記(2015年8月)

2015年8月9日

Bug-org 1186799 composition string in contenteditable element isn't committed when you click outside of the editor
初回投稿日時: 2015年08月09日12時08分21秒
最終更新日時: 2015年08月09日12時09分11秒
カテゴリ: IME Mozilla Core Mozilla42 バグ修正
SNS: (list)

contenteditableなエディタ上に未確定文字列が存在している時に、編集不能なその外側をクリックしても未確定文字列は実際には確定されているものの、未確定文字列の見た目がそのまま残ってしまうというバグです。

原因は、nsHTMLEditorEventListener::MouseDown()が、editing hostの外側でクリックされた場合には何もしていないことが原因でした。

editing hostの外側でクリックが行われると、まず、mosuedownイベントが発生します。これにより、フォーカス移動が発生し、このcontenteditableなエディタはフォーカスを失います。この時に内部ではREQUEST_TO_COMMIT_COMPOSITIONが発行され、ネイティブのIMEに未確定文字列の確定を促し、それが実行されると、NS_COMPSOITION_COMMIT_AS_ISイベント等が発火されます。

通常は、このパターンでもうまくいくはずだったのですが、このケースではcontenteditableなエディタというのが問題でした。

nsHTMLEditorは(仕様が同じ形になりましたが)、ドキュメントにひとつだけ存在し、複数のcontenteditableな要素があっても、フォーカスが移動する度に初期化され、使い回すことになります。このような動作を実現するため、フォーカスを持ったcontenteditableな要素の外側にある要素は編集不能と判断されます。つまり、どのcontenteditableな要素もフォーカスを持たない場合、全ての要素が編集不能と判断されます。

このため、フォーカスを失った後にnsHTMLEditorが受け取った確定イベントは全て、処理に失敗していたのです。

これを修正するために、今回は、フォーカスを失う前段階であるmosuedownediting host外で発生した場合にも強制確定を行うようにしました。若干雑な修正の仕方なのですが、現在、エディタは自分が未確定文字列を管理していない場合には、IMEに対して確定のリクエストを出さないようになっていますので、十分に安全に修正されていると思われます。

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

bug-org 1186799を含むエントリ