この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
例によって、システムイベントグループにイベントリスナを登録していないためにstopPropagation()でデフォルトアクションが実行されなくなる、というバグです。
MathMLのコードをいじったのは意外と初めてな気がしなくもないです。
いつからか忘れましたが、Firefoxのフィードバックを送信することができるようになってますが、書き込まれている内容等々から察するに、システムがよく分かってない方多そうなのでざっくりと説明をしておこうかな、と。
ここに書き込まれた内容は、一般公開されています。個人情報を書くな、という注意書きがあるのはこのためですね。もちろん、言語で絞り込んで表示することができます。
日本語について絞り込んだ結果からすると、日本語版のフォームから書いたかどうかで、内容の言語を直接見ているわけではないことが分かると思います。当たり前ですけど。ですので、日本語版のフォームから書き込む場合には日本語で書き込めばOKですね。逆に、日本語以外のフォームから(例えば英語版のベータ版から)書き込む時はその言語か英語で書かないと、ほぼ確実にその書き込みは埋没して無駄になります。
検索結果を見ると分かりますが、送信者は完全に匿名で、特定することはできません。このため、問い合わせたつもりで書き込んでいる人を時々見かけますが、絶対に返事はありません。連絡先の入力を要求もしていないのに、それは不可能です。返事が欲しいような質問はコミュニティのフォーラムに行くしかありません。
私も時々、内容をチェックして自分の分かる範囲でのバグ等の報告があればbugzillaで調査したり、修正したりしていますが、どちらかというと、残念ながらごくまれです。その最大の理由は書き込まれた内容のクオリティの問題です。
140文字、という文字数制限が確かに厳しいですが、バグ報告としてフィードバックを書く場合は、問題が発生した時に、
この二点は最低限、書いてもらわないと理解できません。結果だけを書いてしまわないように気をつけてください。なお、バージョンは書かなくてもUA名が自動的に記録されていますので、貴重な文字数を浪費しなくても大丈夫です。逆に言うなら、問題のあったバージョンのFirefoxから書き込んでもらわないと理解できないかもしれません。
バグについて詳細に対応が必要なら、ユーザコミュニティのフォーラムに書き込むか、bugzillaを直接利用する方が良いでしょう。
また、バグ報告を見ていて気になるのが、手元では全く再現しないバグが多いことです。
開発コミュニティの一員でもない人が積極的にバグを報告したくなるようなバグというのは大体、重大な問題が発生した時でしょう。そのようなバグが、もしどの環境でも発生しているのであれば、開発者は最優先でそのような重大なバグに取りかかっているはずです。ですので、そのようなバグを発見した場合はあなたの環境固有の問題であることを疑う方が合理的です。
ですので、そのような場合はセーフモードでの確認や、グラフィックドライバの更新等で様子を見てみるべきです。もし、特定のアドオンや、システムに常駐してるソフトウェア等が問題の原因だった場合はその原因を含めて報告しておいてもらえると非常に有益です。
バグが発生した結果はもちろん重要ですが、報告された情報が有益かどうかは、最低限、発生させるためのヒントが含まれているかどうかに依ります。もし、ひとつの報告で十分な情報が得られなかったとしても、同じ結果と共に別のヒントを提供している報告が存在すれば次第にバグの再現のさせ方が絞り込めていきます。
例えば、本体のバグではありませんが、高速リリースサイクルでアドオンの互換性が無くて困るという苦情をよく見かけますが、数字上はそのようなアドオンはほとんど無いはずです。ですので、どのアドオンが無効化されて困ったのか、どのアドオンが無効化されていなかったもののどのような機能に異常が出たのか、その情報が、そのアドオンの互換性を向上させるかもしれません。この場合も「どのアドオンなのか」という事実を確認するためのヒントが重要であることが分かってもらえるかと思います。「アドオンの互換性が失われた」という結果は必要な条件ではありますが、それだけでは価値が非常に低いのです。
ユーザがどういったところを気に入ってて、どういった不満を持っているのか、それが表れるという点では重要です。ただ、見る側は一人で大量にポストしているのではないか、という疑いも持たなくてはいけないので、このツールがこの点で有用かどうかは利用者の方次第といったところでしょうか。
是非報告した方が良いです。単純に見ている人達が見逃してしまっているかもしれませんし、報告の数が増えていくと、特定の環境の問題か、重大な問題ではないと思っていたとしても、そうではないかもしれない、ということが自然と分かってきます。早期解決を望むのであれば問題はどんどん書いた方が良いです。
最後に、やはり私は気軽にバグの情報を書き込むことができて、なおかつ開発者にとって検索しやすいデータベースを作成する必要があると今でも考えています。Bugzillaだと開発者以外には非常に使い勝手が悪いですし、ユーザコミュニティのフォーラムでは利用者も開発者もバグの情報を探しにくいですし、また、Firefox Inputには双方向性がないので、不明な点や、細かい確認を行うことができません。もし、そのようなサービスの構築に興味があり、サーバアプリを書ける方は私に直接連絡してもらえると助かります。
tryserverでテスト中に発見した、簡単に直せるバグだったので、修正したランダムオレンジです。
ページの読み込みや、リフローが発生している場合等はGeckoはJavascriptが実行されて欲しくないので(一部の)イベントの生成を遅らせます。focusイベントとblurイベントはその対象で、このテストの修正後のように発生すべきイベントの発生を確認してからテストを進めないといけません。失敗したらタイムアウトしますが、それはランダムなものではないはずなのでその原因を作ったパッチはすぐにバックアウトされることになります。
自動テスト用のキーイベントの生成ユーティリティがuntrusted eventを生成して利用しているというバグです。untrusted eventでテストすると、フォーカスがあまり関係無くなることや、実際に走るコードが結構変わってしまってテストにならないかもしれないので、好ましくありません。また、untrusted eventの受け入れを止めるアクションが発生する度に多くのテストの書き換えが必要になりますので、ユーティリティ自体がtrusted eventを利用するように修正しています。
この修正により、キー入力をテストで発生させる場合、現実と同じようにフォーカスの移動等までエミュレートする必要がありますので注意してください。
Bug-org 703210の修正によるregressionです。ドラッグを開始した後にもツールチップが出現することがあり、それがLinuxの場合には高頻度でサイトアイコンのドラッグ中に、ブックマークツールバーへのドロップを阻害してしまうというものです。何故、bug-org 703210の修正がトリガーになったのかは理解できていませんが。
nsXULTooltipListenerがdragstartイベントを受け取った後にもmousemoveイベントを受け取ることがあることが分かりました。
もちろん、mousemoveイベントの生成自体が間違っているのでこれの修正をしないといけないのですが、サイクルの終了が近いので、ひとまず、nsXULTooltipListener側でregressionのみを安全につぶしています。
ツールチップが表示されるまでの時間を指定できる設定が欲しい、というバグです。本来ならどうでも良いバグですが、Bug-org 706743の修正で自動テストを作ったものの、これが増えると時間かかりすぎるのが明白なので、ツールチップの表示時間をゼロに設定できるように修正しています。
ランダムオレンジの修正です。
Bug-org 700199の修正でこのテストを修正した時に分かったのですが、実はこのテスト、スクロールしたかどうかの確認をなんと、非同期のスクロールが発生する前に検査していました。何故それがパスしていたかというと↓↑とキーイベントを生成して、元の位置に戻っているか確認していたのを、私がそれぞれのキーイベント直後で検査するように書き換えたので判明しました。そんな訳で、元々のランダムオレンジも非同期でスクロールが発生することを意識していないことに原因があるように思われました。
今回、キーイベントを生成する度にスクロールイベントを待ってから次のステップに移るように変更していますので、完全に修正できていると思われます。
untrusted eventでエディタに入力できるのは止めよう、というバグです。現在のGeckoはkeypressイベントをスクリプトで生成して、送信してやると、任意の文字をキャレット位置に入力したり、削除したりできます。ですが、もっと手軽に編集するAPIは既にありますし、そもそもIE、WebKit系、Operaではこんなことはできません。
この機能は大昔からありましたが、Firefox 1.0.6 (Gecko 1.7.10)の時にregressionでこの機能が利用できなくなると、きちんと動かなくなるサイトがあったようで、Firefox 1.0.8 (Gecko 1.7.13)で復活しています。
当時はまだまだIE全盛の時代でしたが、今はWebKitの台頭と、APIの進化でこの動作の必要性がますます薄れていると思われます。また、textinputイベントの実装に非常に邪魔な機能なのでどうしても削除したかったので、思い切って削除に踏み切りました。
リスキーなので、サイクルが始まったばかりのMozilla12に投入しています。今夜以降のビルドでおそらく入っていると思いますので、それで色々なサイトでテストしてもらえると助かります。
twitterで流れてるのを見て、ちょっと面白そうなネタだと思ったので、個人的な好みとか。
やっぱりビルドやエンコードで公私ともにパワーが必要なのでIntel製。クロックが1GHzな頃から、PhenomeあたりまではAMD使ってたんですけど、最近は性能差がベンチマークでも出過ぎですし、AMDからIntelに移行した時に思ったのが、コンパイラによる最適化があると思われるぐらい、数字以上の性能差をIntel製のCPUからは感じました。
ASUSです。やっぱりクオリティが高いなと感じるのは、長年使っているものの、特にトラブルが発生しなかったという点が大きいです。ただ、堅実な作りではあるので、SATAのポートの数の問題とかで浮気する時は無難にネームバリューのあるGIGABYTEにしてました。こちらも特に悪く無かったですが、SandyBridge-Eのメモリ問題を見てると、やはりASUSの方が何枚か上手かなって感じました。
PCの安定性には地味に重要だと感じているのでケチりはしませんが、かといって特に高いものを買うわけでもありません。CFD等のリテール品で安めのものとか使ってます。ノーブランドはちょっと怖いかな、ぐらいの印象です。
ハードディスク、最近はWestern Digitalばかり買ってます。ちょっと前まではSeagateでしたが、ハズレモデルを引いてしまって、1年の間に6台ぐらい買い換えるハメになったのでしばらく敬遠しようかな、と。そのさらに前はIBMからの流れでHGSTでしたが、プラッタが全体的に一世代前の容量であることが多くて、大容量が必要なので論外になってしまいましたが、モノ自体に悪い印象はありません。
常に10台ぐらいのHDDが稼働してますが、HDDの故障はモデル差と個体差が非常に激しいという印象ですので、一度や二度の故障で信頼を失うとひょっとすると損なのかなぁという気はしています。
システムドライブには安心のIntel製かな、とは思うんですが、OCZ等も使ってたり。まあ、まだまだ歴史の浅いパーツなのでよく分からないです。
特に今のところこだわりはありませんが、ドライブが松下製のものはまず買わないようにしています。リージョンコードの問題なのであまり詳しいことは書きませんが。それからPioneerは買いません。Pioneerのドライブは何故か評判が良いので一時期は買ってましたが、挿入しても認識できないディスクが多かったり、故障があまりにも多いので買わなくなりました。
SATAの増設で信頼しているのはRATOCです。ちょっと高い気もしますけど、まあ誤差? 故障等には未だに当たったことがないだけ、という気もしますが。
どちらもEPSONです。特に理由は無いんですが、PC-9821の頃になんとなくEPSONのプリンタ買ってからずっとそのまま惰性でという感じです。
レーザープリンタは価格の問題からKONICA MINOLTAの安いモデル使ってます。
有線のネットワークではプラネックス製品を愛用しています。世間的には評判がイマイチなようですが、今まで問題にあたったことがないのと、デザインが好みなので。
無線LAN内蔵のルータはNEC一択です。ちょっと高いですが、プラネックス製品とかコレガ製品とか安いのは1年、再起動無しで動くなんてことが経験上ありえないので使い物になりませんでした。
サーバとか公開するようならNECは駄目という話も聞きますが、その辺詳しくないので分かりません。
二大メーカーにはどちらにも信者さんが居るのでここにコメント欄がなくて良かったという感じですが、nVidiaもAMDもどちらも良いんじゃないかと思ってます。良い意味でも悪い意味でもどっちもどっちという印象です。
洋ゲーやる人ならnVidiaの方がアプリ側が最適化してて良いんじゃないかなと思いますし、そうじゃない人にはAMDの方がアイドル時の消費電力が低くて良いんじゃないかと思います。個人的にはトリプルディスプレイの都合上、AMDを選択しています。
よく言われる、動画の画質差ってのはどちらも感じないです。そもそも画質を気にするならGPUの支援機能使うなって個人的には思うんですが……
選択肢としてはクオリティ的にはMicrosoftかLogicool(海外ではLogitech)しか無いと思いますが、どちらが良いか、どちらを使ってるかというのは大人の事情で明言しないようにしておきます。ぶっちゃけ、ここは好みだと思いますし。
売り場で見てるとEIZOとか良いなぁとは思うんですが、そこまで出せないので安くてそこそこ、ということでDELLを愛用しています。DELLは価格は安物に近い部類なんですけど、発色が少なくとも値段よりは遥に良いレベルで、なにより廉価版モデルじゃなかったらコネクタ類が国産メーカーよりは豊富でマトモなんですよね。特に、DisplayPort付きの安いモデルが欲しかったら、他に選択肢がないんじゃないかと思います。
ちなみにノングレアの選択肢があるならノングレアにします。デスクトップだと光沢液晶はそもそも選択肢に入れません。
まあ、あくまでも個人的な感想ですし、体験から来るものなので全く逆の印象を抱いている人とかも居るでしょうし、そういうので論戦とかはしたくないです。
私は長時間稼働させるものや、信頼性が必要なものの場合、同等のスペックにも関わらず、メーカー間でそれなりに価格差が大きいことがある場合には、高い方を買うようにしています。スペック票に出てこない、安定性に大切なパーツ類で削った結果が価格差になっているんだなと、安物買いの銭失いを何度もした経験からくるものです。特に高価なものを買うときほどケチらないように気をつけています。買い直しの時のダメージがデカいですから。
逆にそうじゃないパーツ、周辺機器っていうのは安いもので駄目だったら買い直しかな、ぐらいの感覚です。
この年の瀬に超ブルーなバグを見つけてしまいました。
compositionupdateの送信タイミングに問題があるんですが、GeckoとWebKitはエディタで実際に処理が発生する前にイベントを発行します。それに対して、IEは編集が実際に終わった後に発行されます。
これがどのような違いを産むかというと、そのエディタのコンテンツをcompositionupdateイベントハンドラで取得した場合に違いがでます。GeckoとWebKitでは新しい未確定文字列が反映される前の値が、IEでは新しい未確定文字列が反映された値が取得できます。
ではWebKitではGeckoと同様に最新の未確定文字列を取る方法が無いのかと言うとそういうわけではありません。昔からあるinputイベントがcompositionupdateの直後にやってきます。そして、このイベントのハンドラからエディタにアクセスすると、最新の未確定文字列が反映された値がとれます。
ちなみにIEではinputイベントがcompositionupdateの直前に発行されますが、やはり反映済みの最新の値をとることができます。
Web開発者からすれば少なくともinputイベントでこれらのブラウザで同じように処理できるようになっていることが望ましいでしょう。実際にこの動作の修正は一行修正するだけでGeckoもWebKitと同様に動作するようになります。
しかし話がここで終わりません。
まだ調査中ですが、XULでinputイベントをハンドリングしているコードがそれなりの数あるようです。また、それらのコードは結構な割合でUIになんらかのフィードバックを行っているので、これが未確定文字列の強制確定の原因になる可能性があります。この問題は当然放置できないので全てなんらかの手段で修正、もしくは回避しなくてはいけませんが、中々に頭の痛い問題です。
inputイベントのハンドラで、分かるもので調べてみましたが、特に問題なさそうです。予想外なのが非常に気持ち悪いんですが……