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

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

もずはっく日記(2010年10月)

2010年10月4日

京都・東福寺と壬生寺 初回投稿日時: 2010年10月04日00時08分32秒
最終更新日時: 2010年10月04日00時11分38秒
カテゴリ: 旅行
固定リンク: id=2010100400
SNS: (list)

今週は東福寺と、壬生寺へ。

東福寺と言うと、どちらかと言えば任天堂の方が有名な気がしなくもないですが……まあ冗談はさておき、東福寺は山際にある上に庭園が非常に立派なので来月、紅葉が始まるとかなり綺麗な景色が楽しめそうでした。

四条大宮から見て、壬生寺の手前にある八木家内はさすがに撮影禁止だったので入り口の写真のみです。中では芹沢鴨が寝ていた部屋と、暗殺された部屋を案内されます。暗殺された部屋の鴨居にはそのときの刀傷と言われている傷がありました。

ちなみに、ここのガイドさんによると、新選組は関西では人気が低く、関東の人の方が多く訪れているのだそうです。

壬生寺内の壬生塚には芹沢鴨の墓もありましたが、立派な墓にはしたくなかったのか、建前である「殉職した局長」の墓というイメージとはほど遠いものがありました。

新選組に関連した壬生では京都の他の観光地よりも若い女性をよく見かけました。やっぱり、歴女な方々なんでしょうか?

2010年10月7日

Firefoxのシェアとか、Chromeのシェアとか 初回投稿日時: 2010年10月07日21時45分15秒
カテゴリ: Firefox Google Chrome IE 雑談
固定リンク: id=2010100700
SNS: (list)

念のために書いておきますが、個人的な感想です。

スラドにもありますが、Firefoxのシェアはここ最近はずっと横ばい、Chromeに勢いがあってChromeがすごい追い上げてきています。色々なニュースで似たような結果なので大きく外れた統計ではないのでしょう。

ここで気になるのがどういった層がFirefoxを使い、どういった層がChromeを使っているのか、という点です。私の考える、あまり好ましくない展開というのは、Firefoxユーザはおおむね昔のままで、ChromeがIEのシェアを浸食しているという形です。

それに対して、Mozilla側があまり心配しなくていい展開というのは、FirefoxはIEからシェアを食い続けていているものの、アーリーアダプタ層がChromeへ移動している、という形です。

具体的な根拠は無いんですが、個人的には後者の流れなんじゃないかなと思っています。

ひとつめの根拠としては、いま、Firefoxという商標にはブランド力があるという点です。当たり前ですが、社会の大半の人にとってはブラウザなんてただの道具でしかないですから、長いこと聞いている名前の方がブランド力があると思われます(どちらも同程度に興味を持たれていない場合、という前提ですが)。

それに加えて、Firefox3.6は、IE6とのUIの類似度がIEからの乗り替えに有利に働いているのではないかと思います。今、IEから他のブラウザへ移動する人というのは、既に乗り替え済みの人よりもライトなPCユーザではないかと思います。少なくともアーリーアダプターではもう無いでしょう。そのような人がブラウザの乗り替えを考えた場合、使い慣れていたIE6にUIが最も近い、Windowsアプリケーションとしては伝統的な形のままであるFirefox3.6というのは乗り替えやすいブラウザなのではないかと思います。

Firefox3.6とは反対に、ChromeやIE7、IE8とというのは今までの学習結果を一度破棄する必要があるんではないかというぐらいにUIが変わりました。これは明らかに乗り替えるユーザに大きな負担をかけます。そして、Firefox4もこれらのブラウザと同様のUIに変更されます。そうすると、メジャーブラウザがよく似た、新UIになるわけですが、その後のシェアの変化でFirefoxのシェアが維持されるのか、下がるのかで、ユーザが望むのは使い慣れたクラシックなUIなのか、それともデザイナが理屈によって考えたより使いやすいUIなのかを知るひとつの判断材料になるかもしれません。

2010年10月8日

Bug-org 597981 When Google VKB is opened, Key-Repeat does not work! (On latest gtk2 platforms, keydown events are not dispatched by auto repeat) 初回投稿日時: 2010年10月08日15時38分09秒
最終更新日時: 2010年10月08日16時53分26秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010100800
SNS: (list)

言葉足らずでかなり理解が怪しくなりそうなので、大きく変更・追記しました。

最近のGTK2上でキーボードのキーを押しっぱなしにすると、DOMキーイベントが

  1. keydown
  2. keypress
  3. keypress
  4. ...
  5. keyup

という順序で生成され、keydownイベントを期待しているWebアプリが動かなくなっている、というバグです。

調べてみると、Ubuntu 9.4では、

  1. keydown
  2. keypress
  3. keyup
  4. keydown
  5. keypress
  6. keyup
  7. ...

と、リピート入力時にも、keydownkeypresskeyupがワンセットで生成されていました。

GTK2のネイティブには、key pressイベントと、key releaseイベントのみがあります。Geckoはkey pressイベントを受け取ると、コンテンツに対して、keydownイベントと、keypressイベントを生成しています。

DOM3でキーイベントの発生順序が定義されていなかった時に、Linux版のGeckoは、現在と同じ、

  1. keydown
  2. keypress
  3. keypress
  4. ...
  5. keyup

という順序になるように、keydownイベントを最初のネイティブのkey pressイベントでしか生成しないように、あえて制限を行っていました。

ところが、Ubuntu 9.4当時のGTK2は、リピート時に、key pressイベントだけではなく、key upイベントもワンセットで送信するように挙動を変更していました。これにより、keydownをリピートごとに生成しないようにする、というコードが動くことが無くなっていました。

この時点でGeckoの開発者としてはバグに気づくべきでした。想定していた通りのイベントがプラットフォームからは来なくなっていましたので。しかし、残念ながらこれを自動でテストする手段はまだ見つかっていませんので、この問題は発見されていませんでした。

ここで、Web開発者の視点に立ってみると、DOM3で最近提案されたキーイベントの順序とは異なり、余計なkeyupが来るものの、keypressイベントの前には常にkeydownイベントが必ず発生するようにGeckoが修正されたかのように見えます。

ですが、Ubuntu 9.10以降のGTK2では、リピート時に再び、key upイベントを送信してこなくなりました。このため、Geckoのkeydownイベントの抑制コードが再び動くようになりました。これにより、DOM3のイベント順序案からさらに離れた、昔のイベントの発生順序に戻ってしまい、DOM3を意識したWebアプリケーションの動作に悪影響が出ていたわけです。

今回の修正で、Windows版と同様、DOM3の仕様案通りに、

  1. keydown
  2. keypress
  3. keydown
  4. keypress
  5. ...
  6. keyup

という順序でkeypressイベントの前には必ずkeydownイベントがリピートされるようになりました。

なお、Mac版の修正はBug-org 599887で承認待ちになっています。

2010年10月12日

Bug-org 601440 Cannot enter Return key in location/search bar when input field was focused 初回投稿日時: 2010年10月12日23時53分22秒
最終更新日時: 2010年10月12日23時54分38秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010101201
SNS: (list)

1.9.2 branch限定の深刻なregressionです。なぜ、1.9.2 branch限定かというと、Bug-org 597389と、Bug-org 548480の両方が修正されたのが1.9.2 branchのみだからです。

おそらく直接的な原因はBug-org 548480の方です。その修正内容は、MacのAPI内部で間違えたドキュメントを参照しないように、これを最新の状態にリセットする[NSInputManager currentInputManager]を空呼び出しするようした、というものです。

Bug-org 597389はその空呼び出しを(結果的に)フォーカス移動の度に呼び出すようにするパッチです。

この空呼び出しをネイティブのウィジット間でフォーカスが移動している最中に呼び出すと、古い方のウィジットにキーイベントが送られる状態のまま、フォーカスが移動してしまっているようです(Geckoのイベントからの推測なので、実際にはフォーカス移動がキャンセルされているのかもしれません)。

結局のところ、今回もMacのAPIのバグに泣かされた形です。以前にも書きましたが、なぜこんな意味不明な設計にしたのか、担当者のセンスを疑います。API内部で現在フォーカスを持つウィジットのIMのコンテキストに対して処理を行う、という設計なので、このコンテキストの選択処理がおかしいとこのように意味不明な動作を産むことになります。Appleには是非とも、フォーカスという状態に依存しないIMのAPIを再設計してもらいたいものです。

ちなみに、予定では明日、リリース予定で、本当に滑り込みのチェックインになりました。連休中にパッチが完成したのが大きかったですね。

2010年10月13日

Bug-org 572385 some special keys (e.g. IME related keys) can't be handled on Linux 初回投稿日時: 2010年10月13日00時37分06秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010101300
SNS: (list)

日記検索してみたらどうも紹介し損ねていたようなので、この機会に紹介しておきます。

基本的にWindowsとLinuxは同じキーボードを利用することが多いですが、日本語キーボードの場合、IMEに特化したキーがいくつかあります。これらのキーのイベントがLinux版では発生しない、というバグです。

WindowsではnsIDOMKeyEventで未定義のキーでも、GeckoのDOMキーコードがWindowsのキーコードを基準に定義しているため全てのキー入力に対してキーイベントが発生しています。

しかし、LinuxやMacではキーコードをOSネイティブのものからGeckoのイベントのキーコードに変換する必要があります。しかし、これは当然nsIDOMKeyEventで定義されていなければ変換のしようがないので今まで無視されていましたが、これをクリアコードの須藤さんが6月に修正してくれました。

この修正で追加されたキーコードは、MDCのKey Eventのドキュメントに追記していますので確認しておいてください。

2010年10月14日

2010年10月20日

Opera「ブラウザの拡張の仕様を標準化して、使い回せるようにしませんか?」 初回投稿日時: 2010年10月20日10時36分02秒
カテゴリ: Firefox Mozilla Core News Opera
固定リンク: id=2010102000
SNS: (list)

FirefoxやChrome、Safariといった主要ブラウザが拡張を採用しているにもかかわらず、それぞれの拡張には互換性がない。そこでウェブの標準技術を拡張にも適用し、すべてのブラウザで同じ拡張を使い回せる環境ができれば、開発者はもちろん、ユーザーにもメリットがあるという。

FirefoxのJetPackのような、ライトな部分に関してはあっても良いのかもしれませんが、それで果たして互換性や使い回しができるのかは疑問です。ブラウザ側が拡張用のAPIを用意し、決められたイベントをトリガーに動作を行う、シンプルな仕組みなら実現可能かもしれません。ですが、Firefoxで実際に人気のある拡張は、大きくブラウザ自体に食い込む形で動作しているものも少なくありません。例えば、UIに対して変更を加える拡張の場合、そのいじる対象が開発時に前提とした形である必要があります。こういう拡張はFirefoxのバージョン間ですら互換性がありませんが、その分、相当高度な要求にも応えることができるようになります。

また、MozillaはXULや、UI用の独自CSSプロパティを標準化するように動いていませんが、これにはひとつ大きなメリットがあります。それは標準仕様の改訂を待たずに実装を変更できることです。逆に言えば、こういったプロダクトの進化に関わる部分を標準化してしまうと確実に進化の速度は落ちてしまいます。ですので、このような標準化が開発者にとって都合が良いというのであれば、それはユーザを無視した意見だと私は思います。

さらに政治的な問題も発生するのではないかと思います。拡張仕様はWebコンテンツの仕様とは違ってセキュアであることはそれほど重要ではないのです。そのため、拡張はネイティブアプリケーションと同列の危険性を持っています。ブラウザの全ベンダの拡張のセキュリティと利便性の妥協点が未来永劫、同じレベルを維持し続けられるのでしょうか?

今回のOperaの主張は、Windows/Mac/Linuxで共通のプラットフォームAPIを用意し、どれでも動くアプリケーションが作れてしかるべきだと言ってるように聞こえます。それが技術的に非現実的ではないとしても、アプリケーションの自由度や性能に関わる部分には疑問を抱かざるをえません。

この主張は一部の拡張作者と後発のブラウザのユーザにはメリットがあるかもしれませんが、実際に拡張の恩恵を受けてきたユーザにはメリットは全く無いのではないでしょうか。

2010年10月29日

Bug-org 604124 Nvidia driver stops working, Firefox won't repaint 初回投稿日時: 2010年10月29日16時04分15秒
カテゴリ: Mozilla Core バグ検証中
固定リンク: id=2010102900
SNS: (list)

Bug-org 606983の修正によって一気に進展しています。

出張用に使ってるPCがVAIOのtype Zなんですが、まあ興味のある方はご存知のようにGPUまわりが特殊な機種なこともあるんでしょうか、カスタムドライバが使われていて、これが一向に更新されていません。Minefieldを使っているとすごい回数、GPUのドライバがクラッシュして、その後、ドライバが回復します。いままではこの回復後、ウインドウがのっぺらぼうになったり、変なペイントが行われる、という感じでしたが、上記のBug-org 606983の修正によってクライアント領域にあたる部分は、ドライバの回復後も問題無くレンダリングされるようになっています。

ただし、Firefoxボタン(Minefieldボタン)を表示していると、そのウインドウではAero Glassは死んだままになり、Aero Basicの見た目になります。また、タイトルバーの大部分が真っ黒になり、最小化、最大化、閉じるボタンが使えなくなるままです(表示されていないだけではなく、本来ある場所をクリックしても無反応になる)。

ファイナルリリース後には回復後のレンダリングが完璧になっていないと、絶対に混乱が起きますのでこのバグの修正は重要ですね。

もっとも、VAIOのこのドライバのようにクラッシュが頻発しすぎると、いくら回復後が良くても製品としてはいかがなものか、という感じですので、ブラックリストに入れてもらった方が良いんでしょうけど。

2010年10月30日

Bug-org 608515 After nVidia driver is crashed, Aero glass isn't recovered if Firefox button is visible 初回投稿日時: 2010年10月30日21時28分36秒
カテゴリ: Mozilla Core バグ報告
固定リンク: id=2010103000
SNS: (list)

ドライバクラッシュ、回復後にAeroが死んだままになって、最小化、最大化、閉じるボタンが機能しない件を単独でバグ報告しました。これで修正してもらえると助かりますが……

ざっくりとコードを見てみたものの、非クライアント領域の描画もやったことなければ、DirectXまわりも全然やったことないので何が原因かさっぱり分からずでした。