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

Bug-org 1143197 Unable to enter text in <input type=password> fields when an input method is available (Linux)
初回投稿日時: 2015年03月26日18時28分51秒
カテゴリ: GTK Mozilla Core Mozilla39 バグ修正
SNS: Tweet (list)

Linux版のATOKである、ATOK X3を利用していると、パスワードフィールドで文字が入力できないというバグです。

Bug-org 1143197の修正によるregressionです。

iBus等、一部のIMEでは、未確定文字列の強制確定をgtk_im_context_reset()を呼び出して行おうとしても、非同期で確定が実行されます。もし、フォーカス移動の最中に強制確定のリクエストを出したら、非同期の確定が発生した時にフォーカスを持っている要素のGtkIMContextと、未確定文字列を実際に持っているGtkIMContextが同一のものとは限りません。このようなケースでも期待通りに動作するように、preedit_startシグナルを受け取った際に、「アクティブなコンテキスト」という意味合いで、GtkIMContextを保存しておき、preedit_endシグナルを受け取ったら、クリアするようにしました。この保存しているアクティブなコンテキストがnullptrでは無い場合、GTKのAPIを呼び出す際には、この保存されたコンテキストを利用するように修正を行いました。

この動作でも、通常のIMEだと問題ないのですが、ATOK X3は奇妙なことに、コンテキストがフォーカスを得た途端にpreedit_startシグナルを送信し、preedit_endシグナルは一切送信してきません。このため、常にアクティブなコンテキストが保存されたままになり、フォーカスを持っているパスワードフィールド用のものではないGtkIMContextがキーイベントを処理してしまっていました。

ユーザは、フォーカス位置にあわせてキーを押すわけなので、キーイベントのハンドリング時には、アクティブなコンテキストではなく、フォーカスを持っているコンテキストが常に処理するように修正しました。

しかし、その修正だけでは、ATOK X3がpreedit_endを送信してこないため、強制確定後にもアクティブなコンテキストが保存されっぱなしで、一切キー入力を受け付けなくなるバグも発見しました。これを回避するために、gtk_im_context_reset()を呼び出した直後に、未確定文字列が空にも関わらず、preedit_endシグナルを受け取っていない場合、このシグナルのハンドラを強制的に実行するように修正しています。

ただ、後者の修正は、一部のLinux向けの中国語IMEで不具合があるかもしれません。一部の中国語IMEは、未確定文字列を常に空文字列にしておき、自前のウインドウで未確定文字列の変換を行っているためです。ここに問題が無いという確信が未だにないため、38 ESRで修正されるべきかどうなのか、未だに悩んでいるところです。