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

Bug-org 1083098 Composition string doesn't appear after forcibly commit composition by moving focus on Linux
初回投稿日時: 2014年10月30日22時48分48秒
カテゴリ: GTK Mozilla Core Mozilla35 Mozilla36 バグ修正
SNS: Tweet (list)

未確定文字列があるエディタ以外をクリックして、フォーカス移動により、未確定文字列を強制確定させた場合、Linux GTK版で、iBusを利用していると、次にどのエディタでもIMEの未確定文字列が入力されず、それを一度確定なりキャンセルすると、通常の状態に戻る、というバグです。Bug-org 1065835の修正によるregressionです。

例によってiBusの非同期での未確定文字列のキャンセル処理がバグの原因になっています。

Bug-org 1065835の修正で、非同期で確定、もしくはキャンセルが行われるIMEを利用していた場合、TextCompositionは自動的に、確定、もしくはキャンセルをDOMイベントを生成して、エミュレーションするようになりました。この際に、TextCompositionのインスタンスは、まだ、破棄されないように修正されました。待機して、その後に非同期で発生するはずのIMEから来るWidgetCompositionEventを無視し、DOMツリーでは発火しないようにしなくてはいけないからです。

フォーカス移動で強制確定が行われた場合かつ、IMEが有効なエディタが続けてフォーカスを得ていない場合、同期でnsIWidget::SetInputContext()が呼び出され、nsGtkIMModule::GetContext()の戻り値が、パスワードフィールド用のGtkIMContextか、IMEを利用しないための、ダミーコンテキストに変わってしまっていることがあります。その後、IMEが非同期で確定、もしくはキャンセルのためのシグナルをnsGtkIMModuleに送信しても、その時点でのGetContext()の戻り値とは異なるコンテキストであるという理由で無視してしまっていました。これにより、TextCompositionが期待する、NS_COMPOSITION_ENDイベントが発火されず、これを待ち続ける状態が続き、新しい未確定文字列が表示されなくなっていました。そして、それの確定、もしくはキャンセル時に発生するNS_COMPOSITION_ENDイベントを受け取ることで、ようやく破棄されて、新しい未確定文字列を処理可能な状態に戻っていた、という訳です。

この修正では、シグナルを受信した場合に渡されたGtkIMContextが、Gecko自身が生成して管理しているもののうちのどれかと同じであるかを確認する形に変更しました。これにより、フォーカス移動でnsGtkIMContext::GetContext()が異なる値を返してきてもシグナルを処理するようにしています。また、シグナルを処理するメソッドの一部は、GtkIMContextを引数で受け取るようにし、GetContext()を利用しないようにしています。

Auroraでも修正しないといけないので、最低限の変更にしてありますが、追々、ほとんどのシグナル処理のメソッドが、GtkIMContextを引数で受け取るように修正する予定です。