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

Bug-org 1213589 [TSF] Converting Hangul to Hanja with MS Korean IME converts unexpected range of fixed string
初回投稿日時: 2015年12月30日13時24分18秒
カテゴリ: IME Mac Mozilla Core Mozilla45 TSF Windows バグ修正
SNS: Tweet (list)

TSFモードがデフォルトで有効になってから、韓国向けMS-IMEを、韓国のリッチテキストエディタを利用したいくつかのWebサイトで漢字や記号への変換が期待通りの範囲を行ってくれなくなったというバグです。一ヶ月以上、これにかかりっきりに近い状態の、実に難産なバグ修正でした。

韓国向けMS-IMEでは、Hanjaキー(Hanjaは漢字のこと)を押すと、既に入力済みの文字を変換しようとします。IMMの場合、未確定文字列のみが対象となっていたので、問題が発生することはありませんでしたが、TSFの場合、未確定文字列が変換対象を確定済みのテキストも含めて、最高で直近の改行文字の直後まで遡って探すようになっていました。報告してくれた例によると、안녕하세요(改行)안という文字列の最後でHanajaキーを押した場合、最後の안を変換したいのに、Geckoのリッチテキストエディタ上では안녕が変換対象になってしまうサイトが多々あるとのことでした。

まず、Geckoのリッチテキストエディタの挙動を確認してみると、Enterキーを押したときに挿入されるものがエディタの内容によって異なることが分かりました。例えば、<div contenteditable></div>というエディタだと、<br>要素が挿入されます。それに対して、<div contenteditable><p></p></div>というエディタで、<p>要素内にキャレットがある場合、Enterキーを押すと、そこで<p>要素を分割します(HTMLのソースコードで言うなら、</p><p>を挿入する形)。この、後者の場合が問題でした。

現在、IMEのリクエストに対して返すプレーンテキストはmozilla::ContentEventHandlerで生成されています。この際に、<br>要素は\nもしくは\r\nに変換されますが、他の要素の境界には何も挿入されません。そのため、上記の例が<p>안녕하세요</p><p>안</p>だった場合、生成されるプレーンテキストは안녕하세요안になってしまっていたのです。

そこで、このバグでは、mozilla::ContentEventHandlerの設計を大きく変更し、一部の例外の要素を除き、要素の開始タグの位置にあたる部分に改行文字を挿入して返すようにしました。この変更に伴い、<img>要素等でテキストが分割されている場合にも改行文字が挿入されることで単語の境界が明確になるようになっています。

ContentEventHandlerのこの機能は、Mac OS X 10.10以前では辞書引きの際にコンテンツを返すのに使われていますので、今までよりも期待通りの範囲が辞書引きされるように改善されています(OS X 10.11 El Capitanでは新しいAPIに応答しないといけなくなっているものの、そこが未実装なため辞書引きの機能自体が動作しません)。

時間がとれ次第、閉じタグの位置にも改行文字を挿入するように修正しようと考えていますが、韓国向けMS-IMEで問題が発生するにはかなりあり得ないHTML片になっていないといけないので、優先度は低いです。