この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
恥ずかしいバグ。修正済み。
continueはループ構造の先頭へのジャンプだと思っていたのが原因。continueはループの最後へのジャンプらしい。
こだわっているのは明らかにMozilla Corporationであり、Firefoxという名前が使われなくなって不利益を被るのもMozilla Corporationのほうなのだ。Debianが独自にパッチを適用しているのがTrademark policyに反するというなら、Mozilla側がDebian発のパッチをどんどんレビューしてソースツリーに取り込んでいけばいいだけではないか。
はい。当然、Mozilla Corporationはこだわっています。自社の財産なので、当然のことではないでしょうか? 私はそれを否定しませんし、非難もしません。(ベストな条件かどうかは個人的にも疑問がありますが、ビジネスに関しては素人なので、否定できるほどの根拠はありません。)
確かに、シェアが減るという不利益はありますが、既に--enable-official-brandingではないビルドを使われている時点で(アイコンだけが違うという訳ではないですよね? DebianをVMware上で起動できなかったので未確認ですが)、パートナー企業にとってのシェアは目減りしてしまっています。また、もしもこの特例を認めた場合に、他のディストリビュータ等から「俺も俺も」という話になると、更に不利益が増大します。これを考えるなら、ここでDebianがFirefoxというブランド名を使わない、というのはあまり現状に比べて損なこととは思えません。
また、Debianが取り込んだパッチをMozilla側で自主的に取り込むという件については賛同しかねます。フルタイムの従業員が100人もいないような小さな会社ではそんなこと不可能ですし、できたとしても、現実的とは思えません。そもそも、それができるなら、最初からサポートを打ち切っていないですよ。
ああ、そういう懸念もあるなぁ、と納得。
Mozilla FoundationやMozilla Corporationのせいではないミスを、MFやMCのせいにしてしまっていたかも知れない。MFがMFの判断で取り込んだパッチのせいで問題が起こるならそれはMFのせいだけれども、MFのあずかり知らぬ所で起こった出来事の責任をMFのせいにするというのは、僕の倫理観では「許されないこと」です。
もし、信用を一度失うと、その回復は、一からの構築よりも難しいことが多いです。例えば、Fx1.0の時に不評だった、自動アップデートに関する不備や、日本語版のみ、リリースが数日遅れていた件等。未だにこの件を欠点としてあげられてることがあることを見ると、一度試して駄目だった場合、再度インストールしてもらう、というのがいかに難しいことかと実感します。これは、一度見て、駄目だったWebサイトを二度はなかなか訪れてくれない、ということと似ていますが、面倒な点を考慮するとそれ以上かもしれません。
そういう意味ではFirefoxのシェアが今のところ、日本では他国よりも低め、というのも後で考えれば幸運だったと感じることができる可能性もあります。今のリリース分ではまだIMEへの対応が非常に低レベルですが、Fx3以降では改善されるので(Mozilla Japanのプロダクト本体への貢献の大半はtrunkにしか入っていないためです。)、初めて触る人には、Fx3を触ってもらった方が良いのではないかと常々思います。(もっとも、Fx3はまだこれからリファクタリングが入ってくるので、安定したリリースビルドができあがるかどうかは不透明ですが。)
闇黒日記さんより。
SEOとかアクセスアップとかは結構だが、インターネット專門誌は「企業サイトを印刷してみる」特集なんて組んでみたら如何だらうか。 InternetExplorerのみならず、FirefoxやOpera、それもWindowsとMacintosh、或はLinuxで印刷してみる。
企業のプレスリリースなんかを資料としてプリントアウトしてとつておかうとする、ところがブラウザによつて・ユーザの設定によつて變な風に印刷されてしまふ――「この時、企業の信用は、そのユーザにおいて決定的に崩れてしまふ事だつてあり得る」。
面白いアイデアだと思います。それもとても有用な。
ブラウザ側のバグを差し引いても、元のサイトのCSSが印刷を考慮していないこと、というのは非常に多そうに思います。(私も印刷を意識してCSSを書いたことなどほとんど無し。)
テーブルレイアウトとか、幅固定してるサイトなんて論外な結果が得られるのが普通でしょうけど、そういうサイトがまだまだ多いですし。(印刷も考慮するようになっても、単にメディア指定で、印刷の場合はA4で適切になるように幅固定しときゃ、いいやん、みたいな馬鹿サイトも増えそうな気もしますが。挙げ句の果てにはA4で印刷してください、みたいな馬鹿な注釈をつけたり。)
印刷というのは、おそらく一番身近で、表示性能がスクリーンと同等以上の表示デバイスとだと思うので、これが注目されればCSSデザイナのレベルを上げる良い機会になるのかもしれません。複数のデバイスで柔軟に表示できるものを作ろうとするなら、より抽象的な設計が必要となるので、よりきちんとしたレベルでCSSを理解しなくてはいけなくなるでしょうから。
ただ、このように難しい状況に作成側が置かれていった場合にオーサリングツールがどのように進化するのかも興味があります。
そして、現段階では印刷機能がぼろぼろなFirefoxの改善への原動力になってくれるかもしれません。
懐かしのＭＳ (Ｐ)ゴシック、ＭＳ (Ｐ)明朝の問題(バグ?)。
斉藤さんのパッチがthebes作成時に無視されていたのが原因だったので、その時のパッチを参考に同じロジックを入れてみた。
Jokerさんの情報によると、MacのデフォルトウイジェットがCocoaになったものの、Webページ上のボタンとかはCocoaネイティブな見た目にしない模様。
デザイナにとっては万歳、ユーザにとっては残念、という感じ?
Linuxのテキストレンダリングが豪快にぶっ壊れてる。
パッチ作ったものの、応答無し。こういう時に時差が不便。まあ、寝てる間に小人さんが仕事やっちゃってくれてた、という感じの状況が多いのも事実だが。
IRCで連絡がとれたので修正完了。
以前tinderboxを燃やしてしまったこのバグも修正完了。
Linuxでもcairoビルドなら新しい行高算出処理を利用するようになったので、一部の環境では日本語フォントの行間がつまりすぎるという問題が修正されているかもしれない。
明日は緊急じゃないパッチを書けたらいいなぁ。
数日前から挙動不審な感じはあったミラーリングしていたドライブがお亡くなりに。物理的に死んだのは片一方だと思われますが、どちらからもファイルを救出することはできませんでした。全体的にほとんどバックアップの無いデータが中心に消失してしまいました(容量にして120から130GBぐらい)。ミラーリングしているからと、このドライブに集中してため込んでいたのが仇となってしまいました。
ミラーリングに過信していてはいけないという教訓を得たと前向きに考えるしか無いような状態です。
やっぱりマシン二台以上で冗長性を持たせる、というのが経験上は安全確実なようですが、LAN越しにGB単位のデータを二重化するのも現実的ではないので、とりあえず一台のPC内で二台のHDDに手動でバックアップしていくことを計画中です。といっても定期的に実行されるように自動化する必要はありそうですが。
ちなみに、開発に直接使っていたツール、データ関係は無傷なので出張から帰ってくればハックにはすぐに復帰できる見込みです。
報告者がパッチを提供してくれたので報告から30分で終了。(Tinderboxの監視が今までかかったが。)
Vladのコメントによると、やはり旧gfxは全て利用しなくなる模様。
この前のbug-org 356235の修正で、いよいよVC6でのビルドができなくなったらしい。
公開。
例によってオフィシャルな文書という訳ではないのでご注意を。
メジャーリリースとセキュリティフィックスのためのマイナーアップデートをごっちゃにしてはいけません。
自動でメジャーアップデートしちゃうと、すごい混乱が起きますよ。
ようやく最終草案となるパッチを提出。
テストできる方はテストして欲しい。Linuxでのパフォーマンスはrv0.6までよりは高速化しているが、現在の設計ではパフォーマンス低下は避けられない。それは別バグで問題として挙がっていて、後日修正となるのでそれは心配しないで欲しい。
MacOSもなんとなくやり方は分かってきているが、今回は見送り。現在のコードがそれ以前のデキなので。
Windowsはフォントリンクにも対応できそうなコードになったが、それは次回に見送るつもり。最悪、1.9 finalに入っていなくても支障はないレベルの機能だし。
BeOSはLinuxと同じくfontconfigを利用しているのでコードをそのままコピーしているが、環境が無いのでビルドテストはできていない。
メジャーアップデートでは自動アップデートは行われないというのだったら話はすっきりします．
はい、それですっきりします。自動でメジャーアップデートは行われません。
Fx1.5のマイナーアップデートは今後メンテナンスが続く限り利用可能です。つまり、1.5.0.xから1.5.0.x+1はメンテナンス終了まで続きます。
ですが、Fx1.5とFx2は同じコードベースなだけで、全く別物であるということです。例えば、拡張機能が一部動かなくなったりします。テーマに至っては全く駄目でしょう。また、Geckoそのものにも若干の修正が入っていますし、Javascriptのエンジンに至っては若干どころではない修正が入っています。これを自動で行えば、企業ユーザ等には間違いなく混乱が起きます。また、大抵の場合、メジャーリリースの一番最初のビルドには問題が含まれていることが多いので、少し様子を見てからアップグレードしようという人も居るかと思います。ですが、自動アップデートではそのような要求に応えることもできません。
ところで、メジャーアップグレードを自動でやってしまうというのはMicrosoftの無料アップグレード以外では私は聞いたことがありません。この場合、Microsoftも非常に神経をとがらせています。例えば日本語版のIE7は他国より半年遅れでしか自動アップデートされません。(いかに日本人が保守的な民族か、というのが浮き彫りな話ですが。)また、Windowsのサービスパックだと、自動アップデートさせないためのツールを配布したりしています。開発者としては残念ですが、メジャーアップデートは万人の需要ではないのです。
また自動アップデートは Firefox 1.5 で導入された目玉の機能なのでメジャーアップデートはその限りでないのだったらもう少し宣伝されていないと Firefox 1.5 以来既に７回も自動アップデートをの恩恵に浴している大多数の人にとってむしろ混乱を招くと思うのですが．
もちろんです。宣伝方法について意見があればよろしくお願いします。(MJのサイトに告知は出ると思いますが、ナレッジベースに出ている情報を質問する人も多い中、どれくらいその告知に効果があるかは疑問です。)
しかし 1.5.0.8 -> 2.0 のメジャーアップデートで自動アップデートが出来るようになるという話はどうなのでしょうか？
少なくとも私はそういう情報は確認していません。
先週、社内でミーティングした段階では自動でのメジャーアップデートは無いと聞いています。
修正したものの、nsIKBStateControl::ResetInputStateが動いてなかったりと、色々と問題山積。
修正完了。
フォーカスを持ち、イベントを生成するwidgetとエディタのオーナーとなるwidgetは別物の模様。ということはnsIKBStateControl自体、ちょっと良くない設計だなぁ……
OSCで、も組のMさんに拉致されて出て参りました。
まず、開発者を増やすのは難しすぎるので、開発者の負担を減らすためにもテスタを増やそうよという話に嫌になるぐらい納得してしまいました。開発者を増やすというのはテスタに比べて圧倒的に大変です。開発者には当然コーディングの能力は要求されますし、なんらかの専門知識(Web標準仕様の知識だったり、プラットフォームの知識だったり)も要求されますし、何よりボランティアには難しい、まとまった活動時間が要求されてしまいます。テスタだと、専門知識と、若干の時間さえあればなんとかなるというあたりが決定的に違います。(別に楽な作業という訳ではないです。私もボランティアでテスタやってた時は睡眠時間を削ってましたから。)
また、他のプロジェクトでは中間層が居ない様で、ドキュメントまわりとかが大変な状況なんだとか。この辺はMozilla関係とは全く正反対な状況でちょっと不思議です。Mozilla関係者はフリーライダーも多いですが、和訳やドキュメント整備等でプロダクトそのもの以外の件でも汗を流してくれている人もかなり多いので助かってます。今の状況だけ見れば分母の大きさが、と言えますが、ギークのおもちゃだった当時から現在とあんまり変わらない体制があったわけで、Mozillaは特殊な例なのかと思ってしまいます。
で、一番興味深かったのがIMのフレームワーク周りのお話。進行中の話のようなので、ここで詳細は書くのを控えますが、整備するというのであればアプリケーションのデベロッパという立場では是非議論に参加したいと思える内容でした。アプリケーションを開発してる側からみると、GTK2のIMまわりの自由度というのはWindowsに比べて非常に低くてGeckoでもIMを無効にするためだけでも、無茶苦茶トリッキーな手法を使っています。それでも解決できただけマシで、OSCで講演したように未だに解決不能で困っている問題は残っている訳です。で、話を伺ったところでは、やっぱりIMまわりの設計というのはIMのエンジンの開発者等にとってどうなのか、という視点が中心で作られていて、アプリケーション側からの視点はほとんど無い状態だったとのこと。まあ納得です。とりあえずGTK2というツールキットはことIMとの連携に関しては駄作としか言いようのないデキなので今後の関係者の活動に期待大です。
他にもフォント周りとか印刷周りの話もありましたが、そちらはまあLinuxなんかでは以前から言われてることですね。改めて大変な問題なんだということが再認識できました。