もずはっく日記(2016年1月)

Bug-org 1242331 [e10s][TSF] When typing fast, IME composition may be committed unexpectedly and input won't cause text input after that
初回投稿日時: 2016年01月30日23時32分13秒
最終更新日時: 2016年02月18日11時06分50秒
カテゴリ: e10s Mozilla Core Mozilla46 TSF Windows バグ修正
SNS: Tweet (list)

e10sモードで、TSFモードでWebコンテンツに入力していると、子プロセスがビジーな場合、入力中の未確定文字列が強制的に確定され、再度入力しなければいけなくなるというバグです。

強制確定は、フォーカスのあるエディタ内のテキストが、TIPの未確定文字列変更以外で変更された場合(Javascriptでの変更を元々は想定)、TSFやTIPが混乱してFirefoxを再起動するまで日本語入力ができなくなるのを避けるためにTSFTextStoreが予防策として行っています。

e10sモードで子プロセスがビジー状態になっている場合、未確定文字列の入力中にその未確定文字列の入力が始まる前に直接キーボードで入力した内容まで、TIPが意図していなかったテキストの変更として通知されてしまいます。そのため、上記の予防策がユーザの正常な入力を妨害してしまっていました。

今回の修正では、TextChangeDataBaseに、mIncludingChangesDuringCompositionとmIncludingChangesWithoutCompositionを追加しました。前者は、IMEへの通知を待っているテキスト変更のデータが、IME以外による変更が未確定文字列が存在している時に起こったかを記録し、後者は、IME以外による変更が未確定文字列が存在しない時に起こったかを記録しています。ここで重要なポイントは、その時点の未確定文字列の編集が開始される前の未確定文字列の編集中に発生した変更は、未確定文字列が存在していない時に起きた変更として扱うようにしていることです。つまり、現在の未確定文字列の編集が始まる前の変更は全て、未確定文字列が無かった時の変更として記録・通知されます。

これにより、TSFTextStoreは、現在の未確定文字列の編集が始まって以降にTIP以外が原因でテキストに変更があった場合にのみ未確定文字列を強制確定するようにしました(つまり、元々の意図通りに動作するように修正しました)。

ただし、勘の良い方は気付かれたと思いますが、この状態が発生すると、TSFTextStoreはTIPからの問い合わせに正しく応答できなくなるパターンが存在します。例えば、空のエディタに「あいう」という文字列を入力、確定し、次に「え」と入力したとします。もし、子プロセスがビジー状態で、「え」を入力した時点で、まだ、先の入力処理を終えてなかったとします。すると、「え」の開始時にTSFTextStoreはオフセット0の位置に入力を開始したと誤解してしまいます。そして、前の文字の入力完了の通知が来ると、例えば未確定文字列の1文字目の内容をTIPが取得しようとしても、確定済みの先の確定文字列の1文字目が返されることになります。

このため、候補ウインドウの位置がおかしくなったりする諸々の新しいバグが発生することになりますが、今時のPCであれば、極端に様々な処理がバックグラウンドで走りまくっているサイトを開いていなければそうそう問題にはならないと思います。

この辺の問題に対する抜本的な解決は今年のQ2以降での修正を予定していますが、もちろん、パッチを書いてくれる人が居ればレビューしますので気軽にレビューのリクエストを私に投げて下さい。

どうしてもこのバグが発生してしまう環境であったり、そのような「重い」Webサービスを利用する場合は、about:configから、intl.tsf.enableをfalseに変更してFirefoxを再起動し、TSFモード自体を無効化してください。