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

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

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

2018年7月12日

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 バグ修正
固定リンク: id=2018071200
SNS: (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を返さないように修正しています。