この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
なんと、fixedとなりました。
comment 23によると、仕様書は再びLast Callに戻るのですが、その際に::selectionが削除されるので、そこに掲載されるセレクタの実装は全て完了した、とのことです。
例えば、縦スクロールバーのみを持つサブフレーム上でマウスホイールからスクロールさせると、body等の別の横スクロールバーをホイールで横スクロールしようとしても、ホイールによるスクロールのターゲットが、最初のサブフレームにロックされているため、何もスクロールできずに混乱する、というバグでした。あまり発生するようなバグではないですが、この辺の実装をやっている私自身が何が起きてるのか分からずに混乱させられるぐらい、実際に出会うと何が起きているのか理解に苦しむバグです。
今回の修正で、ホイールを回転させてスクロールしようとしても実際にスクロールしなかった場合、ホイールスクロールのトランザクションを更新しないように変更しました。つまり、ホイールによるスクロールを失敗し続けていると、そのうちにそのトランザクションはタイムアウトして、スクロールターゲットがリセットされるようになっています。
具体的に言うと、まず縦スクロールバーしか無いサブフレームを縦にスクロールした時点で、サブフレームがスクロールターゲットとしてロックされます。その後、ユーザが他の横スクロールバーのために横スクロールのホイールイベントを生成してもすぐには横スクロールは実行されません。つまり、何もスクロールしない状態になります。ですが、そのまま横スクロールの操作を継続しているとサブフレームへのロックが外れて、新しい横スクロール可能なターゲットを探して、スクロールを実行します。
これにより、当初からの、意図しないスクロールが行われないようにする、という話との両立を図っています。
実はパッチ自体は昨年末にほぼ完成していたのですが、一連の機能を自動テストに追加しようという話が出たのでその作業にかかりっきりでした。できあがった自動テストは1400行を超えるという非道い規模になってしまいました。レビュアから修正点を指摘されて修正を入れるとテスト自体がregressionを起こすという複雑さでした。スクロールイベントが非同期で発生する上に、javascriptにはsleepに該当する機能が無いので、このようなものになっています。興味のある方は見てみてください。
Bug 5669の自動テストのために、テスト用のDOMイベントを追加したのですが、そのテスト用のDOMイベントはWebページからもaddEventListenerを使うことでハンドリング可能です。Webページがこのテスト用のDOMイベントをハンドリングしている最中にスクロールターゲットを削除してしまうことでGeckoをクラッシュさせることができてしまう、というバグです。
既に修正済みで、最新のnightly buildでは安全です。
Bug 6302のregressionで、windowedなflash playerでタブキー等のFxもハンドリングするキーを押すと、flash playerが処理すると同時に、Fx自身も処理してしまっているため、期待通りに動かない、というバグです。
えむけいさんが当該バグで指摘されているように、この辺は改善の余地がある問題なのですが、bug 6302の修正目的はあくまでもwindowlessモードでのIMEの利用を可能にするためのものだったので、それ以外の挙動はできるだけ元のままであることが好ましいと判断し、キーイベントは従来通りflash playerが常に食ってしまうように修正しています。
今はまだtrunkのみでの修正ですが、数日間様子を見たあとで1.9.1 branchにも投入予定です。
Linux版でもメニュー関連のサウンドも再生されるようになったようです。
チェックインだけでも色々とあって苦労しましたが、ようやくTSFの最初のサポートパッチが入りました。
TSFとはテキストサービス(Text Service)と呼ばれるアプリケーションから、TSF対応アプリケーションにアクセスしてテキストの情報をやりとりするWindowsの新しい仕様で、かなり高度な機能を実現しています。Windows自体が対応しているのはWindows XP SP1以降とWindows Vistaのみです。Windows 2000やWindows Server 2003ではMS Office XP以降のインストールでTSFがインストールされます。日本人にとって最も身近なテキストサービスはMS-IMEで、TSFではIMEのことをTIPと呼びます。
現在はまだMS-IMEでの挙動すら怪しい部分が多いので、デフォルト設定でTSFサポートは無効になっていますが、intl.enable_tsf_supportをtrueに変更してFxを再起動することによって有効化してテストすることができます。バグを見つけた場合はBugzilla-jpに要約の先頭に[TSF]を付けてバグ登録を行ってください(もちろん、初めて利用する方ははじばぐに目を通してコミュニティの性質を理解してください)。
今のところTSFのバグ修正は私一人であたってる状況なのでFx3.2のリリース版でどこまでまともなものに仕上がるかはかなり不透明ですが、バグ報告がなければ何も始まりません。当面はバグ自体の重要度以上に、修正が大規模なもの、リスキーなものから優先して行く予定です。MacのFlashの時みたいに、またファイナルリリース直前という手遅れな状況下で突然大声出すような人が出ないように、アルファ段階からの積極的な開発者の活躍に期待しています。
なお、ATOK、Japanistといったサードパーティの商用IMEはTSF非対応ですので、従来のIMM32の処理で動作します。
TSFのサポートパッチの投入を今日までこの日記で紹介していなかったのはこのバグのためです。XPに付属のMS-IME 2002では未確定文字列が表示されない、というバグがありました。そのため、テストすらまともにできない、という状況下だったためです(そんな中でもバグをXPで探し続けてくれたmasaさんに感謝です)。
原因はTIPでの処理順序にあります。最初の実装ではITfContextOwnerCompositionSink::OnUpdateCompositionが呼び出された時に未確定文字列の表示を行っていたのですが、MS-IME 2002ではこの時点では未確定文字列の文節等の情報が出揃っていないことが分かりました。
そこで出揃っている場合はここからNS_TEXT_TEXTイベントを生成するようにしましたが、未完成の場合はITextStoreACP::SetSelectionでも生成するように修正しています。ただし、未確定文字列のちらつきを抑えるために、同じ情報のイベントを複数回送信しないように、イベント生成の直前でそれをチェックするようにしています。
要約通りのバグです。
Geckoは一応、埋め込みにも対応しているので、親ウインドウの変更をうまく知る術がありません。そのため、TIPで変換作業が行われている場合は、タイマーで強引に0.1秒間隔で未確定文字列の場所を再問い合わせするように、TSFに促すように修正しています。これにより、遅いPCでは処理速度に問題が発生しているかもしれません。また、特定のIMEでは変換ウインドウの表示がちらついたりする可能性はあります(TIPの実装の仕方次第)。パフォーマンスについては、開発機では全然問題無いレベルでしたが、開発機はそんなに遅い訳ではないので(それなりに速くないとビルドに時間がかかって仕事にならない)、古いPCだとキツイ可能性はあります。ですから、できるだけ多くの人のテストをお願いしたいところです。
Windows用Safariの新しいWindowsネイティブルック：Windows標準のフォントレンダリングとネイティブタイトルバー、ボーダー、ツールバーを使い、ほかのWindows XPやWindows Vista用アプリケーションと同様の操作感を実現する。
おおっ。と感心してダウンロードして試してみましたが、ツッコミどころ満載なUIになってて、なんというか(悪い意味で)Appleらしいというか。とりあえず、このSafari4を見て、違和感を感じずに操作できるWindowsユーザは居ないと思います。そんなレベルで(Windowsアプリとして)変。
IEが7からUIが一般的なアプリケーションからかなり離れて行ってしまったので、Windowsで一番ネイティブっぽい見た目のメジャーなブラウザがXPアプリとして最初から設計されたFxになっている、というのはなんか奇妙な話です。
TSF関連のバグでひとつ忘れていました。
WinXPに標準でインストールされているNatural Input 2002を利用すると、Fx内でフォーカス移動する度にIMEがオンになってしまう、というバグです。
Natural Input 2002の設定画面を見てみると、「起動時の入力モード」という項目があり、デフォルトで「ひらがな」が選択されています。
NI2002ではフォーカス移動時にTSFのドキュメント、もしくはコンテキストごとに「起動した」と判断しているようです。Geckoは、各エディタ毎に個別のドキュメントとコンテキストを持っているかのように振る舞うので、フォーカスを別のエディタに移す度に起動時の入力モードに変更されてしまう、という問題が発生します。
ですが、これはTSF-awareなアプリケーションでは既知の問題のようで、NI2002の仕様、もしくはバグのようです。現に、NI2003では問題無いそうです。以上の理由から、NI2002のこの挙動は仕様通りであるとしてinvalidとしました。
ひとつだけGeckoのバグと言えるのかもしれないのは、Geckoはフォーカスがエディタから移動する際に、そのエディタのためのドキュメントとコンテキストを逐一、破棄しているため、NI2002でオフにしたエディタに再びフォーカスを戻した時にもオンになってしまうという挙動です。
ですが、これを解決しようとすると、一度フォーカスを得たエディタのドキュメントとコンテキストを、そのエディタが破棄されるまで保持し続けなくてはいけません。これを実現しようとすると、非常に多くのオブザーバを(NI2002のためだけに)登録して、ドキュメントとコンテキストを管理しなくてはいけませんが、NI2002自体がこのバグのために使い物にならないのであれば、無駄な実装と言ってしまっても良いと思います。そのため、バグとして登録されても私は今のところ実装に乗り気ではありません。他のテキストサービスで有用な利用が可能なのであれば話は別ですが……
そういう訳で、Fx3.2ではWinXP標準搭載のNatural Input 2002の利用は非推奨です。Natural Input自体、評判悪いようですが、どうしてもこれが使いたい場合、Office 2003に付いているNatural Input 2003をインストールして利用してください。