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

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

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

2015年3月2日

ime-modeの標準仕様からの削除について 初回投稿日時: 2015年03月02日13時03分57秒
最終更新日時: 2015年03月02日13時10分43秒
カテゴリ: CSS Firefox IE Windows
固定リンク: id=2015030200
SNS: (list)

CSS3-UIの仕様書からime-modeの定義が削除され、各ブラウザベンダは直ちに実装を中止し、サポート済みのブラウザも実装を削除すべきだという文言に変更されました

スラッシュドットでも取り上げられてて、多くのコメントが寄せられてました。参照されてる記事読まずに、書かれたコメントも多くて非常にアレではありますが、それはさておき、情報が混乱してるのは確かな訳なので、軽くまとめてみようかと。

ime-modeは本当に削除されていくのか?

あくまで私見ですが、少なくとも短期的にはあり得ないと思っています。そのような話がbugzillaで出てきても、Firefox (Gecko)からの削除は私自身が反対します。

その最も大きな理由は、代替技術が存在しないということです。次に、ime-modeを利用して、入力を効率化しなくてはいけないシステムというものが日本には存在し続けていると考えているからです。

ime-modeはWindowsのIMEの挙動を基にした、決して綺麗ではない定義になっています。ですので、Windows版以外のFirefoxでは問題を色々と抱えています。しかし、逆に言えば、Windowsでは期待通りに動いてくれるのです。

ここで、ime-modeが必要だと考えてるターゲットが誰なのか、ということが重要です。これを実装した私自身は、企業内のイントラネットで使われているWebブラウザ上で動作する社内システムでの利用を前提にしています(おそらくMicrosoft側もそうだと思います)。

私自身はMozillaで働き出して、もう10年近くが経過しているので、最近の日本企業によるシステム構築の際の要求事項に明るくありません。しかし、私が前職で得た知見では、間違いなく、IMEの状態を管理したいという要求があり、それはおそらく現在でも変わることはないだろうということです。

ime-modeについての一番大きな誤解は、これを利用することで、システムの発注側は入力できる内容を絞り込みたいんだということです。実際には、それは違います。彼らは、IMEのオン・オフや、ひらがな固定、カタカナ固定、漢字混在、半角英数での入力といったIMEのモード管理という、本来の業務から、システム利用者(普通は社員もしくはそれに近い人)を解放し、効率化したいのです。そういった要求が変化しているとは考えられません(クライアントが非Windows環境になっていればまた別ですが)。

そういったユーザが想定される状況下で、代替技術もなく、Webブラウザが実装を削除してしまうというのはWebブラウザをシステムを動かすプラットフォームとして選択してくれた、ブラウザベンダ側からすると有り難いことこの上ないユーザを切り捨てるでしょうか? あり得ません。

IMEの入力状態はユーザ自身で管理しないと混乱を生むだけだからime-modeは悪だ!

あなたが一日に数回程度以下しか利用しないWebページのフォームについてこう言っているのであれば、それは正しい意見だと思います。

ですが、ime-modeの利用シーンはより過酷な状況を想定しています。

社内システムで決まったフォーマットの情報を入力する業務では、一日に何十回、何百回と同じフォームにデータを入力することも考えられます。一回のフォームでの入力で、IMEを5回、オン、オフしないといけない場合を考えてみてください。1日に100回、そのフォームを利用しなくてはいけない場合、1日で500回、IMEのオン、オフを切り替えていることになります。これが一週間、5日で2500回、年間だとおそろしい回数の無駄な作業が発生します。

何らかの同じ作業をPCでこなそうとするときに、「なんでこの機能が自動化されていないんだ」とか、ちょっとした開発が可能な人なら、「面倒なので自動化しよう」と思ったことはありませんか?

つまり、利用者側が自動でIMEの状態を管理して欲しい場合には、無くてはならない機能でもあるのです。

逆に、通常のWebページ(例えば顧客が使うページ等)で利用すると、そのような同意がシステム設計者とユーザの間で得られてないので、ime-modeは不快感を与えてしまうため、使うべきではないのです。

標準仕様がime-modeを否定したんだから、やっぱり削除すべきでは?

それがWebブラウザを利用しているほとんど全ての人にとって有益であればそうすべきです。また、他のWeb標準仕様と整合性がとれなくなるのであれば、ケースバイケースですが、原則的にはそうすべきです。

しかし、上述のように、これを必要と考えているであろうユーザが簡単に推測できてしまいます。そのようなユーザを切り捨てるには、メンテナンスコストがかかりすぎるなど、それなりのメリットが必要ですが、それを見いだすことは私にはできません。現状、サポートをやめることの方がデメリットが大きいのです。

仕様書が実装から削除されるべきと言及するのは間違っているのでは

私もそう思いましたので、代替案込みでW3Cに意見をポストしていますime-modeの削除に否定的な人が、何故行動を起こさないのか、不思議で仕方ないですね。特に、日本語の事情を全然考慮してくれていないとか言ってる人は論外でしょう。こういう時こそ、冷静に要求を入れていかないといけないのですから。私の意見はあくまで想像に基づいた私見でしかないので、企業ユーザの前提が間違っていると考えるのであれば、是非、W3CのMLでご自分の意見を表明してください。

私の意見は、ime-modeを置き換えるAPIやCSSプロパティが標準化、実装されるまで、ブラウザはime-modeをサポートしていても良い、という文章に書き換えるべきだという内容です。

ime-modeはやはり標準化されるべきでは?

ime-modeはやはり仕様書で標準化され、全てのブラウザで利用できるようになるべきだと考える人も居るかもしれません。

また、そこまで積極的ではなくても、ブラウザが引き続きime-modeをサポートするのであれば、標準仕様がそれを標準化しておくべきだと考える人も居るかもしれません。

ですが、私はime-modeの標準策定には反対です

上述のように、ime-modeはWindowsのIMEの挙動をコントロールすることのみを考えた、スマートではない定義になっています。Macでは、IMEが無効化された後、有効化されても、入力モードは復元されません。Linuxでは、そもそも、アプリからIMEのオン・オフは切り替えられないので、実装が不完全です。

また、最近のトレンドでは、IMEのフレームワークが拡張され、タッチスクリーンからの入力、スピーチ入力も一元的に取り扱うようになってきています。このような状況下で、額面通りにIMEを無効にすることを許可する訳にはいきません。

非常に長い時間がかかると思いますが、まったく新しいAPIの形を考えるべきでしょう。それまでは、グレーゾーンに存在し続けるという今までの状況が、誰にとっても都合が良いのです。

2015年3月26日

Bug-org 1061604 [TSF] Needs hack for wrong candidate window position of Google Japanese Input 初回投稿日時: 2015年03月26日17時40分00秒
最終更新日時: 2015年03月26日17時40分14秒
カテゴリ: Mozilla Core Mozilla39 TSF Windows バグ修正
固定リンク: id=2015032600
SNS: (list)

Google日本語入力をTSFモードで使うと、候補ウインドウ位置が一瞬だけ変な位置に表示されてばたついたりするというバグです。MSDN SubscriptionがWindows 8系が出る前にライセンスが切れてしまっていたので、日本語版以外のWindowsでの挙動が確認できず、修正が遅れていましたが、ようやく修正を行いました。

問題は、例によって、ITextStoreACP::GetTextExt()から、TS_E_NOLAYOUTを返すと、TSFがTIP(この場合、Google日本語入力)に、E_FAILを返してしまうため、Google日本語入力の方で、ひとまず適当な位置にウインドウを配置した後、正しい位置が判明した際に本来の位置を移動され、ばたついた表示になっていました。

Windows 10 TPではこのバグがTSF側で修正されているようで、症状が改善しますが、若干、ばたつくケースがあるようです。これは、Google日本語入力自体のバグではないかと思われます。

Bug-org 1140832 Cannot undo Input Method commit by Ctrl + BackSpace 初回投稿日時: 2015年03月26日18時00分18秒
カテゴリ: GTK Mozilla Core Mozilla39 バグ修正
固定リンク: id=2015032601
SNS: (list)

Bug-org 1065835のregressionにより、Linux上でMozcで確定後、Ctrl+Backspaceで確定アンドゥができないというバグです。

Bug-org 1065835の修正で、GTK版Geckoは、キャレットの移動時に逐一、gtk_im_context_reset()を呼び出すようになりました。GTKのドキュメントによるとこれはIME側にとって期待される動作だと思われます(GTKのドキュメントが不明瞭で意見が分かれがち)。

Mozcは、確定アンドゥがキックされると、未確定文字列を生成する前に、直前に確定した範囲を自動選択し、未確定文字列で上書きしようとします。しかし、最初の自動選択の際にgtk_im_context_reset()を呼び出すと、Mozcは始まっていない未確定状態をそのままキャンセルしてしまっていました。

Mozcの開発者や、Googleの湯川さんの話からも、IMEからのリクエストが原因で選択範囲が変更された場合には、gtk_im_context_reset()を呼び出すべきではないという結論に至ったので、そのように修正しています。

現在、時期ESRである38での修正を申請中です。

Bug-org 1049488 [TSF] Enable TSF mode in default settings in Aurora 初回投稿日時: 2015年03月26日18時05分26秒
カテゴリ: Firefox Mozilla Core Mozilla39 TSF Windows バグ修正
固定リンク: id=2015032602
SNS: (list)

現在、TSFモードはNightlyでのみデフォルトで有効化されていますが、これをAuroraでも有効にし、来週リリース予定のFirefox Developer Editionのユーザからのフィードバックも受けようというものです。

特に重大で修正が困難なバグが無ければ、夏までに、TSFモードをリリースビルドでもデフォルトで有効にする予定ですので、バグ報告をお待ちしております。

Bug-org 1143197 Unable to enter text in <input type=password> fields when an input method is available (Linux) 初回投稿日時: 2015年03月26日18時28分51秒
カテゴリ: GTK Mozilla Core Mozilla39 バグ修正
固定リンク: id=2015032603
SNS: (list)

Linux版のATOKである、ATOK X3を利用していると、パスワードフィールドで文字が入力できないというバグです。

Bug-org 1143197の修正によるregressionです。

iBus等、一部のIMEでは、未確定文字列の強制確定をgtk_im_context_reset()を呼び出して行おうとしても、非同期で確定が実行されます。もし、フォーカス移動の最中に強制確定のリクエストを出したら、非同期の確定が発生した時にフォーカスを持っている要素のGtkIMContextと、未確定文字列を実際に持っているGtkIMContextが同一のものとは限りません。このようなケースでも期待通りに動作するように、preedit_startシグナルを受け取った際に、「アクティブなコンテキスト」という意味合いで、GtkIMContextを保存しておき、preedit_endシグナルを受け取ったら、クリアするようにしました。この保存しているアクティブなコンテキストがnullptrでは無い場合、GTKのAPIを呼び出す際には、この保存されたコンテキストを利用するように修正を行いました。

この動作でも、通常のIMEだと問題ないのですが、ATOK X3は奇妙なことに、コンテキストがフォーカスを得た途端にpreedit_startシグナルを送信し、preedit_endシグナルは一切送信してきません。このため、常にアクティブなコンテキストが保存されたままになり、フォーカスを持っているパスワードフィールド用のものではないGtkIMContextがキーイベントを処理してしまっていました。

ユーザは、フォーカス位置にあわせてキーを押すわけなので、キーイベントのハンドリング時には、アクティブなコンテキストではなく、フォーカスを持っているコンテキストが常に処理するように修正しました。

しかし、その修正だけでは、ATOK X3がpreedit_endを送信してこないため、強制確定後にもアクティブなコンテキストが保存されっぱなしで、一切キー入力を受け付けなくなるバグも発見しました。これを回避するために、gtk_im_context_reset()を呼び出した直後に、未確定文字列が空にも関わらず、preedit_endシグナルを受け取っていない場合、このシグナルのハンドラを強制的に実行するように修正しています。

ただ、後者の修正は、一部のLinux向けの中国語IMEで不具合があるかもしれません。一部の中国語IMEは、未確定文字列を常に空文字列にしておき、自前のウインドウで未確定文字列の変換を行っているためです。ここに問題が無いという確信が未だにないため、38 ESRで修正されるべきかどうなのか、未だに悩んでいるところです。