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

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

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

2015年12月30日

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: (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片になっていないといけないので、優先度は低いです。

関連するかもしれないエントリ

bug-org 1213589を含むエントリ

このエントリへのリンク元

このエントリを参照しているURIはありません。