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

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

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

2018年6月2日

Windows 10のビルド 17643で、TS_E_NOLAYOUT問題が解決されたとのことなので検証してみた 初回投稿日時: 2018年06月02日01時09分54秒
カテゴリ: IME TSF Windows
固定リンク: id=2018060200
SNS: (list)

TSFのTS_E_NOLAYOUT問題とは何かということについては、以前書いた記事を参照してください。

今年初頭に、Windows Insider Meetup in Japan 3にお邪魔して、「この問題なんとかならないですか」とお願いしてみたところ、早くも以下のような嬉しすぎるお返事が来ました。

早速試してみようと思ったら、運悪くSkip Aheadの申し込みが既に終了していたので、Fastリングに降ってくるのを待つことに。そしてようやく、新しいビルドが手に入り、ひたすらATOKのインストールも終わり、この記事をまとめる時間がとれました。

Windows 10 x64にインストール可能な有名どころのIMEをがんばって入れまくっていくとこの画像のような感じになる

Microsoft IME (日本語版)

日本語版のWindowsに標準でインストールされている、いわゆる、MS-IMEです。Geckoは、こちらに対しては、キャレット位置への問い合わせ時と、未確定文字列内の特定の文字の矩形の問い合わせ時には、TS_E_NOLAYOUTを返さないようにしています。

Microsoft IME 日本語版の候補ウインドウ

これらの設定(intl.tsf.hack.ms_japanese_ime.do_not_return_no_layout_error_at_caretとintl.tsf.hack.ms_japanese_ime.do_not_return_no_layout_error_at_first_charを無効にしても、特に変わりなく動作することを確認できました。

ただし、希に、候補ウインドウ、推測候補ウインドウ共に、初めての表示時に画面左上に表示され、その後、おそらくレイアウト変更完了の通知で正しい位置に再表示される、ということがあるようです。あまりにも希すぎて、これが再現した時のログを取得するのが困難なのでどうしたもんかという感じですね。

Google日本語入力

Google日本語入力に関わられてたNyaRuRuさんがもともとこのTSFのバグを見つけられたので、Google日本語入力自身がこのバグに対策をとってくれています。ですので、今回の検証でも、候補ウインドウ位置、推測候補ウインドウ位置共に問題無く表示されていました。

ちなみにバージョンは、2.24.3250.0となっていました。

Google日本語入力の候補ウインドウ

ATOK 2017

ATOK 2017は実は、それ以前のATOKと大きく違う点があります。それは、ATOK 2016以前はATOK側で、Firefoxの過去のバグに対応するためのハックがいくつかあったようなのですが、それをお願いして全て削除してもらった最初のバージョンがATOK 2017です。ですので、今回は検証していませんが、ATOK Passportの最新版の挙動もこちらに準拠していると推測されます。

ATOK 2017の候補ウインドウ

こちらの方は、まず、現在のハックを有効にしている状態でも一つだけ問題があります。それは、未確定文字列のうち、二文節目以降を選択している時に候補を高速に切り替えると(例えばスペースキー押しっぱなし)、候補ウインドウが一文節目の下に一瞬表示され、その後、二文節目の下に移動します。つまり、ちらついているように見えます。

ATOK 2017向けのハックは、未確定文字列内の矩形を問い合わせて来た時にTS_E_NOLAYOUTは返さないというもの(intl.tsf.hack.atok.do_not_return_no_layout_error_of_composition_string)だけですが、これを無効にすると、上記の問題は再現しなくなりました。ただし、文節の位置に関係なく、候補ウインドウが一瞬だけ少しだけ上に表示され、その後、下に移動するという、若干ちらついた表示になります。

この問題は、おそらくGecko側にあるのではないかと推測しています。と言うのも、Geckoは問い合わせ位置に文字がまだ無く、代わりにキャレットがある場合、そのキャレットの矩形を返すのですが、キャレットの高さは文字の高さよりもやや低いことがあるためです。これは次のWindows 10の大型アップデートまでに修正してしまいたいところです。

ATOK 2016

ATOK 2016の動作はATOK 2017と似ています。このバージョンから、推測候補ウインドウは一文字目の下に表示されるようになったのですが、推測候補ウインドウが表示される時というのは、単に文字を追加入力していくだけですので、一文字目が変更されることはありません。そのため、安定して一文字目の矩形を返せるので推測候補ウインドウの位置がちらつくことは無くなっています。それに対して候補ウインドウの位置は、高速に候補を切り替えていくと、数ピクセル右にずれて、その後、本来の位置に移動する事でちらつくことがあります。

ATOK 2016以前のATOKへのハックは上記の未確定文字列内の矩形の問い合わせに対してTS_E_NOLAYOUTを返さないというもの(intl.tsf.hack.atok.do_not_return_no_layout_error_of_composition_string)と、ネイティブキャレットを非表示で生成するというもの(intl.tsf.hack.atok.create_native_caret)の二種類があります。

まず、キャレットの生成を無効化してみると、ATOK 2017と同様に二文節目以降の候補ウインドウが一文節目の下に一瞬表示されるというバグが発生しました。これは、Bug 1273510でATOK向けのハックをATOK 2017以降では無効化する際の検証漏れですね。ATOKでは文節を先頭からひとつずつ確定していくのが標準の操作方法なので気付きませんでした。

ですが、未確定文字列内の矩形の問い合わせに対してTS_E_NOLAYOUTを返さないというもうひとつのハックを無効化すると、この問題も無くなりました。ただし、ATOK 2017と同様に、高速で候補を切り替え中に、本来の位置よりも数ピクセル上に一瞬だけ表示され、本来の位置に戻るというバグがあります。

ATOK 2015
ATOK 2014
ATOK 2013
ATOK 2012
ATOK 2011

ATOK 2011からATOK 2015までは候補ウインドウと推測候補ウインドウに関してはまったく同じ動作でした。

まず、ハックを有効にしている状態だと、候補ウインドウは、候補を高速に切り替えていくと、本来の位置より数ピクセル右に表示され、その後、本来の位置に戻るというちらついた表示になります。また、推測候補ウインドウは、常に最後の文字の下に表示しようとするため、たまに一瞬だけ本来の位置よりも数ピクセル上に表示され、その後本来の場所に戻るというちらついた表示になります。

ATOK 2015以前のATOKへのハックはATOK 2016と同様に未確定文字列内の矩形の問い合わせに対してTS_E_NOLAYOUTを返さないというもの(intl.tsf.hack.atok.do_not_return_no_layout_error_of_composition_string)と、ネイティブキャレットを非表示で生成するというもの(intl.tsf.hack.atok.create_native_caret)の二種類があります。

まず、ネイティブキャレットを生成しなかった場合、候補ウインドウ位置、推測候補ウインドウ位置共に安定し、つらつきが無くなります。さらに、未確定文字列内の矩形の問い合わせに対してTS_E_NOLAYOUTを返しても特に問題が見つかりませんでした。

Japanist 10

Japanist 2003から14年、昨年2017年に発売されたJapanist 10です。Japanist 10ではようやくTSFのTIPとなりました。バージョンは10.10.1.0となっていました。

Geckoは、Japanist 10に対しても、未確定文字列内の矩形の問い合わせに対してTS_E_NOLAYOUTを返さないというハックがあります(intl.tsf.hack.japanist10.do_not_return_no_layout_error_of_composition_string)。これが有効なままであれば、候補ウインドウの位置は問題無く、推測候補ウインドウの位置は一文字目の入力時に表示するように設定していると、一文字目の場合にだけ、画面左上に表示されてしまいます。

このハックを無効にしてみると、最初にフォーカスをセットしたエディタ上では、推測候補ウインドウが文字入力の度に消えることが多くなり、かなり鬱陶しいちらつきを見せます。また、時々候補ウインドウが画面左上に表示されます。

さらに別のエディタにフォーカスを移動させると、推測候補ウインドウは常に画面左上に表示されるようになり、候補ウインドウは最初の候補の時だけ本来の位置に表示された後、その後は常に画面左上に表示されるようになります。

常に候補ウインドウが画面左上に表示されるようになったJapanist 10

Microsoft Pinyin
Microsoft Wubi

中国語(簡体字)向けのIMEです。共に詳しい操作方法は知らないのですが、文字の入力を開始すると、横長の候補ウインドウが表示されます(役割というか挙動は推測候補ウインドウですが)。

Microsoft Pinyinのウインドウ

この表示は、TS_E_NOLAYOUTを返さないようにするハック(intl.tsf.hack.ms_simplified_chinese.do_not_return_no_layout_error)を無効にしても変わることなく正常に処理されているように見えました。

Microsoft Bopomofo

未だに使い方の分からないIMEです。変換を試みてもインラインで変換結果が表示されるだけで、候補ウインドウの表示があるのか無いのか、よく分かりませんでした。

Microsoft ChangJie
Microsoft Quick

中国語(繁体字)のIMEです。共に未確定文字列を入力して変換すると、日本語用IMEの用に候補ウインドウが出ます。

Microsoft ChangJieの候補ウインドウ

さらに確定後に次の候補がある場合、推測候補ウインドウが表示されるというのが簡体字用IMEとはちょっと違うところです。

Microsoft ChangJieの推測候補ウインドウ

これらにもTS_E_NOLAYOUTを返さないようにするハックがあるのですが、有効・無効に関わらず、どちらのウインドウ位置も正常に表示されているように見えました。

Chinese Traditional Array (version 6.0)
Chinese Traditional DaYi (version 6.0)

これらも中国語(繁体字)のIMEなのですが、名前からも、また、以下のUIを見ても、どうも積極的にはもう開発されていなさそうなIMEです(でもWindows 10自身が持っている)。こちらは未確定文字列を入力するだけで候補ウインドウが表示されます。

Chinese Traditional Arrayの候補ウインドウ

また、確定後に即座に推測候補ウインドウが表示されます。

Chinese Traditional Arrayの推測候補ウインドウ

Microsoft IME (韓国語版)
Microsoft Old Hangul

ハングル用のIMEです。やはり、漢字へ変換したい時に、右Ctrlで候補ウインドウが表示されます。

Microsoft IME (Korean) の候補ウインドウ

候補を切り替えても未確定文字列が変化しないので、安定して表示されます。Geckoも特にハックは行っていないです。

ちなみに、日本語版も、韓国語版も"Microsoft IME"という呼称なのはややこしいので、どうにかしていただきたいところです。

Windowsという唯一のプラットフォームがバグっていたにも関わらず、TS_E_NOLAYOUTとレイアウト変更の通知を受け取るというTSFの非同期描画にはJapanist 10以外は対応できているという驚くべき事実が判明したので、Windows 10のバージョンを確認して、これらのハックが行われないようにしていきたいと考えています(Japanist 10のスタッフにも連絡したいけど、どこへ連絡すれば良いんだろう……)。