もずはっく日記(2015年8月)
2015年8月9日
Bug-org 1187566 [TSF] TSFTextStore::Content should compute mMinTextModifiedOffset only with the latest composition string and original composition string
初回投稿日時: 2015年08月09日11時01分01秒
最終更新日時: 2015年08月09日11時03分38秒
カテゴリ: IME Mozilla Core Mozilla41 Mozilla42 TSF Windows
SNS:
Tweet (list)
Google日本語入力の安定版では候補ウインドウ位置を決める時にITextStoreACP::GetTextExt()が失敗すると、ウインドウの左下に表示してしまうことがあるバグがあります。TS_E_NOLAYOUT問題が修正されているWindows 10でも発生しますので、Google日本語入力自体のバグのようです(開発版では修正されているとのことですが、時間がとれなくて、まだ未確認)。
元々、TS_E_NOLAYOUT問題対策でGeckoが入れているコードで、最初の文節でのみこの症状が抑えられていました。ですが、2文節目以降で発生していたので、Gecko側のこのハックに何らかの問題があるのではないかと調査してみたところ、Google日本語入力の独特の挙動により、意図通りに動いていないバグを見つけました。
Google日本語入力は、未確定文字列が変化する際に、最初に未確定文字列全部を空文字列で置き換えてきます。次に、新しい未確定文字列を挿入します。このため、TSFTextStore::Content内で、ドキュメントロック中にどの文字以降に変化があったのかを調べた際に、常に未確定文字列の最初の文字から変化しているという判定になってしまっていました。
そこで、未確定文字列がドキュメントロック中に2回以上変更されても、ロック前の未確定文字列と最新の未確定文字列を常に比較し、それまでの変更が取り消されていないかを確認するようにして対処しました。
このバグはe10sの有効・無効に関わらず発生しますので、TSFモードが最初に有効になるMozilla 41でも修正予定です(既に承認されていますが、パッチはまだ入っていない状態)。
TS_E_NOLAYOUT問題については一度ドキュメントにまとめないといけないかもしれませんね。