もずはっく日記(2018年7月)

Bug-org 1468917 When the ATOK2016 candidate window pops up, it flickers if browser in maximized size mode
初回投稿日時: 2018年07月12日17時36分14秒
カテゴリ: e10s IME Mozilla Core Mozilla62 Mozilla63 TSF Windows バグ修正
SNS: Tweet (list)

ATOK 2016を利用している際に、ウインドウを最大化すると候補ウインドウが一瞬画面端に表示されるというバグです。

GeckoはIMMのコードでは、古い中国語IMEがネイティブキャレットからReading Windowや候補ウインドウの位置を決めていたことに対応するために、Geckoがキャレットを描画している位置に見えないWindowsのキャレットを生成していました。このため、ATOKはGeckoのなんらかのバグに対応するためにこのキャレットの位置情報を利用するようになっていました。そして、この情報が無いと古いATOKではうまく候補ウインドウの位置等が安定しないため、ATOKがTIPになってから(ATOK 2011から)もATOKがアクティブな場合にはネイティブキャレットを生成するようにしていました。

一方で、ATOK 2017以降ではこちらからお願いして、Geckoに対するハックを全て削除してもらい、Gecko側で全て対応するようにしたため、ATOK 2017以降ではWindowsの不可視のキャレットは生成しないようにしていました。

そして、色々と検証してみると、ATOK 2016で候補ウインドウの位置決め等のコードが大きく修正されているようで、ATOK 2015以前では問題なく、ATOK 2016のみの問題であること、また、不可視のキャレットを生成しなければ再現しないことが分かりました。これを放置するとATOK 2016ユーザにはregressionとなってしまうので、こちらもあわせて修正しています。

幸い、ATOK 2016では不可視のキャレットを生成しなくても候補ウインドウ、サジェストウインドウの位置決定に特に問題が無いことが分かりましたので、ATOK 2017以降のみならず、ATOK 2016でも不可視のキャレットの生成は行わないように変更しました。

しかし、ATOK 2017以降にも共通する問題なのですが、ATOK 2016以降で不可視のキャレットが存在していない場合、二文節目以降を変換するために候補を変更していくと、候補ウインドウの位置が一瞬だけ未確定文字列の一文字目に表示され、その後、変換中の文節の下に表示されるということを繰り返すバグがありました(TS_E_NOLAYOUT問題解決に関する検証の際に言及しているバグです)。

後者の原因はシンプルで、TS_E_NOLAYOUT問題を回避するために、ATOKからの文字の矩形情報の取得時にTS_E_NOLAYOUTを返さないようにしていたのですが、ATOKからの問い合わせは未確定文字列全体の問い合わせしか無いという前提でblacklist化していたのが原因で正しく機能していませんでした(ATOKはデフォルトの操作方法では一文節ずつ確定していくため発見できていませんでした)。62以降では、未確定文字列の一部だけの矩形を取得しに来た際にもTS_E_NOLAYOUTを返さないように修正しています。