この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
1.9.0 branchにもパッチを投入し終わりました。
Bug 6305の投入にあわせて、こちらも1.9.0 branchに再投入しています。
MozillaBuild 1.3を単にインストールしただけでは、64ビット環境ではビルドできません。以下、修正が必要なポイントです。
VS2008でしか動作確認していませんが、VSのインストールパスが格納されているレジストリ位置がx86版とは異なるため、修正が必要です。
16行目のMSVCROOTKEYの値をHKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudioに変更しなくてはいけません。ただ、Express Editionの場合はその下でこの変数を使わずにダイレクトにレジストリのキーを指定しているので、そちらを修正しなくてはいけません。
また、VS2008では必要ありませんが、それ以外のバージョンのVisual Studioを利用している場合、おそらく71行目のSDKROOTKEYの値をHKLM\SOFTWARE\Wow6432Node\Microsoft\MicrosoftSDK\InstalledSDKsに変更が必要と思われます。
54行目からのifのブロックはエラーの原因となります。このブロックを丸ごと削除してください(Visual StudioがExperess Editionの場合は、削除する訳にはいかないので、ちゃんとした修正が必要だと思います)。
MozillaBuild 1.3に同梱されているmsys-1.0.dll(mozilla-build/msys/bin/msys-1.0.dll)は64ビット環境には対応していないので、1.0.11以降のものに置換する必要があります。
bash起動時にmozilla-build/msys/bin/ssh-agent.exeが起動されますが、これが暴走してしまいます。特に必要無いものなので、ファイル名を適当にリネームしておけば、bash起動時に自動起動されなくなります。
bugzilla-jpの方に、Linuxでのregressionが報告されたので、一旦バックアウトして、Linuxでのみ挙動を変更しないように修正した、新しいパッチをレビュー申請しています。
trunkの時には報告がなかったのですが、たぶんtrunkでも条件を整えれば再現するはずのバグです。LinuxはWindow Managerが多々あるので、この辺の問題は非常にたちが悪いです。
IMEの自動テストのために、JavascriptからnsIWidgetが管理しているIMEの状態を取得できるようにする必要がある、というバグです。
今のところ、読み取り専用のプロパティにする予定ですが、拡張作者の方で設定できたらこういうことが出来て便利なんだ、という意見、アイデアのある方はバグの方にコメントをください。ただ、XPレベルでのIMEの状態管理は非常に難しいので、かなり説得力のアイデアが近日中に出ない限りは読み取り専用のままで行きたいと考えています。
ものすごく長引いてしまいましたが、ようやく修正完了です。regressionが無ければ1.9.0branchにも投入予定です。
モディファイアキー(Ctrl、Altキー)が押されている場合、モディファイアキー無しで入力される文字列と比較して、同じであればモディファイアキー付きでDOMイベントを生成し、違っていればモディファイアキーを消費(consume)して、モディファイアキー無しでDOMイベントを生成する、という仕様が原因の一端でした。
Geckoのエディタはモディファイアキー付きのDOMキーイベントは文字入力として処理しないので、このようなややこしい仕様になっています。つまり、文字入力のためのキーイベントであれば、モディファイアキーを消費してDOMキーイベントを生成しなくてはいけません。
AltとCtrlが両方押されている — つまり、AltGrが押されている — 場合、モディファイアキーが押されていない場合に入力される文字列と比較して、異なる場合のみ消費する、という処理を行っていました。そのため、AltGrキーの状態に関係無く、入力可能であるべき9と0でのみ、このバグが発生していたのです。
当初のパッチは単純にこの比較をしないようにしていたのですが、Altキーのみが押されている場合に文字が入力できるようになってしまうregressionがパッチのレビュー通過後に発見できたので、新パッチではAltGrキーが押されている場合のみ比較せずにモディファイアキーを消費するように変更し、それ以外の場合は従来通りの処理を行うようになっています。
Mac版のGeckoではCaps Lockキーを押した時にkeydownイベントとkeyupイベントが生成されていない、というバグです。
Cocoaの変な仕様上、Caps Lockキーのkeyupイベントを生成することができないっぽいので、ひとまずkeydownイベントのみ、生成されるように修正しています。
現在、Bug-org 459820でこの修正用の自動テストの作業中です。
Bug 6370の自動テスト、完成しました。
作業中に、ひどく目に付いたので修正しました。多少はビルド速度が向上してますかね :-p
なんでかGoogleニュース経由で知った記事ですが、何の拡張なのかすげー気になります。
結構興味深い数字が多いので、私見を書いてみます。
まず、前提条件を把握しておく必要がありますが、何故かこれが6ページ目に記述されています。詳しいことはそちらを直接見てもらうとして、この情報から私が推測する回答した集団のイメージは、もともとブラウザに興味のある人、ブラウザには興味ないけど日経読者でPCもしくはWebに興味のある人、との混成で、加えてアンケートに率先して回答するポジティブな人という感じでしょうか。年齢層も20代以下はほとんど居なくて、30代以上、というのも特徴的です。これが日経の特徴なのか、それとも年代ごとのWebに対する興味の度合いなのかは不明ですが、前者が色濃いのではないかと思います。
最初の設問は「使ったことがあるブラウザ」、というものですが、ここでは約半数の人がFxを利用したことがあると回答しています。FxのIT系ニュースサイトでの露出の多さを考えると、回答者の半数はブラウザ自体には興味がない人達かもしれません。Google ChromeとSafariは四分の一の人が試してます。このことから、ブラウザに興味があって、アグレッシブに情報を集めている人達はこの割合、と言えるように思えます。
そして「メインブラウザ」を問う設問で、IE7とFxが拮抗し、IE6がそれに近い数字を持っているという、少し変わった結果になっています。Fxのシェアが世間で認知されているシェアよりも高いので、PCやブラウザに対するリテラシがインターネットユーザ全般の平均よりも高いのではないか、ということがここからも伺えます。
「現在のブラウザの直前に利用していたブラウザ」を問う設問では、Netscapeが14%もあります。このうち、何割がFxに移行せずに他のブラウザに流れたのかは少し気になります。仮に全員がFxに移行したのだとしても、Netscape時代からIEを経由せずに来ているかなり熱心なユーザではないユーザが15%程度、Fxの内、半数程度がそうであることになります。ようやく半数まで来た、と考えるべきなのか、まだ半分、と考えるべきなのかは微妙な問題です。
その次は「利用シーンによるシェア」です。ここでIE6が一割を切っている、という点は気になります。IE7へのアップグレードは任意となりましたし、Vistaの普及率もIE7のシェアを伸ばすには影響が少なそうなことを考えると、多くの人がIE6からIE7(もしくは他のブラウザ)にスムーズに移行できている、ということが言えると思います。互換性を理由に、未だにIE7に移行せずにIE6にこだわる書き込みを見かけることはありますが、それは少数派になりつつある、と言える数字だと思います。逆に言えば、IE6でしか使えないような駄目サイトの淘汰がいよいよ本格的に進んでいる、と言えるのかもしれません。
続いて「メインブラウザの利用期間」の設問があります。IEは長期間利用しているユーザが予想通り、他のブラウザよりも多めです。惰性や慣れでIEを利用しているユーザはまだまだ多い、と考えるとまだまだシェアを伸ばすことは可能なのでしょう。
対して、Fxは3年以上使っている古参ユーザが思ったよりも少ないので、うまくシェアを伸ばしているということがこの数字から分かります。また、分厚い層はメジャーバージョンアップがあった時期と重なります。メジャーバージョンアップは宣伝効果もありますし、新機能が気に入ってもらえたり、乗り換えを検討するために試してもらう良いキッカケになっている、ということなのでしょう。ただ、今後はバージョンアップのサイクルが今までとは異なり、変更は少なく、その代わり短いサイクルになっていきますので、メジャーバージョンアップの宣伝効果は薄れてしまわないか、というところが懸念されます。実際に興味のない人への宣伝効果としてメジャーバージョンアップは一番大きなインパクトを持っていると思います。ですが、それ以外でこういった人達に訴求する他のネタ、というのはちょっと思いつきません。その点で、今後のリリースサイクルはマーケティングには不利な材料なのかもしれません。
次の「メインブラウザの決定理由」では、IEはあまり満足されていない、Fxは満足度が高い、ということが伺えます。この設問ではいくつか気になり点があります。まず、カスタマイズのしやすさや拡張性の高さをFxのメリットに挙げている人が約4割という高い割合で居ます。私はこれらの数字は高すぎると感じています。なぜなら、カスタマイズしたがる、積極的なユーザの比率が高すぎる、つまりライトユーザの比率はやはりまだまだ低いと言えるからです。別の視点から考えるなら、まだデフォルトのままでは不便だと考えている人が多いのかもしれません。もちろん、ニッチな機能を追加できることが良い、という意見から出てきた数字なのであれば、あまり心配はしなくても良いのかもしれませんが、どうもそうではないように思います。
次に、速度をメリットにあげているユーザがFxで半数以上も居ることが興味深いです。実測はともかく、体感速度では他のブラウザの方が優秀と感じることは多々あります。ですが、パフォーマンスを重視するユーザでも、パフォーマンスだけでブラウザを選択している訳ではない、と言えるのではないかと思います。
次の設問は満足度に関するシンプルなものです。ここで見る限り、全体的にブラウザを問わず、満足度は高いようです。使い続けているのですから当たり前といえば、当たり前かもしれません。IE6は不満足度が最も高いですが、この一つ前の設問によると、IE6を利用しているユーザのうちの4割は、勤務先でのルールを理由に使っているとのことですから、このへんが原因かもしれません。
最後の設問の「今後使ってみたい、興味のあるブラウザ」ではGoogle Chromeが圧倒的な数字を見せつけてくれています。やはりGoogleの知名度は恐いです。また、Firefoxが2割近いのは考え物です。Firefoxはメジャーリリースを既に何度も行っているので、興味があるなら既に試してもらっていなくては困ります。もしかすると、この数字はブラウザをインストールするという作業を非常に面倒に感じている人の数字と言えるのかもしれません。それも比較的PCのリテラシが高いと思われるこのアンケートの回答者の間で、です。
最終ページで紹介されているいつも同じものを使用しているため、何が不便かわからない
という意見に代表されるように、ブラウザを変えることによるメリットをより分かりやすく、より単純にアピールしなくてはいけないのかもしれません。
Bug 6370のregressionでした。単純にイージーミスで、変数を見るはずが定数で条件判定を行ってしまい、キーダウンイベントしか発生しないようになってしまっていました。
Bug 6387の自動テストの作成バグです。Windowsではまだテストがうまく動かないので、落ち着いたらWindows版もテストを入れることになります。
Linuxの動作には影響しないパッチが改めて1.9.0 branchに投入済みです。regressionが無いか、テストをお願いします。