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

Bug-org 1234120 [IMM] Either Google Japanese Input on Win7 or Japanist 2013 doesn't show suggest window at correct position after previous composition string is committed
初回投稿日時: 2015年12月31日00時08分50秒
最終更新日時: 2015年12月31日00時09分30秒
カテゴリ: IME Mozilla Core Mozilla44 Mozilla45 Mozilla46 TSF Windows バグ修正
SNS: Tweet (list)

Firefox 42以降、TSFモードで、IMMのIMEを利用すると、文字を確定後に新しく未確定文字列を入力し、変換しても、適切な位置に候補ウインドウが表示されないというバグです。

TSF-awareなアプリケーションであっても、従来のIMMのIMEをサポートするには、従来のアプリケーションと同様にIMMのメッセージをハンドリングし、IMM-IMEが期待するAPIを呼び出して候補ウインドウ位置を設定する必要があります。この、候補ウインドウ位置を指定するコードは、現在の選択範囲を基準に動作していることが多いのですが、Bug-org 1184449の修正によって、IMMHandlerはその選択範囲をIMEContentObserverから送信される新しい選択範囲の情報をキャッシュし続けて、負荷を減らすようになりました。ところが、TSFモードが有効な場合、IMEContentObserverに対して、TSFTextStoreが必要とする通知の情報だけを渡していました。このため、IMEが原因で発生した選択範囲の変更を受け取れていませんでした。

今回の修正では、このような矛盾を解消するために、TSFモードが有効かつ、IMMモードのサポートも行っている場合は、どちらか一方でも必要としている通知を要求するようにし、それぞれが不要な通知は無視するように修正しています(どちらかだけを設定した場合、ユーザがIMM-IMEと、TSFのTIPとでスイッチした場合にIMEContentObserverにそれを通知、再設定する手段が無いため、対応しきれない)。

また、この修正により別のregressionも発生が露見し、候補ウインドウ位置がそれだけでは期待通りの位置に表示されなくなっていました。

その原因はBug-org 555642の修正で、IMMHandlerは、IMEの指定するキャレット位置が変換ターゲットの文節内にある場合に、キャレットを非表示にするためにeCompositionChangeイベントで送信しなくなったため、IMMHandlerのキャッシュしているキャレット位置と、実際にGeckoが非表示で設定しているキャレット位置とにズレが生じ、スクリーン上のキャレット位置に候補ウインドウを表示させようとするとGeckoの非表示のキャレットの位置に表示されていました。

こちらのバグは、eCompositionChangeイベントの発火時にキャッシュしていたIMEの指定したキャレットのオフセットを破棄することによって解決しています(常に指定したオフセットの文字の矩形を問い合わせてそこに候補ウインドウを配置するようになるため)。