この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
toolkitのバグ。私の修正したbug 4805のregressionである。
Trunk/1.8 branch双方で修正完了。
一部の画像を表示しようとするとクラッシュしていたこのバグが修正された。
Google Mapを見ることができなかったのは痛かったのでかなりありがたい。
実際の思惑がどうであるかはさておき、こういう風に言われるにはそれなりの理由というものがやっぱりある訳で。
まあ、難しいところですよね。
Mozilla Japanができたそもそもの理由というのが、法人ではないもじら組ができないことをできるようにするためにっていう部分がありましたから、結局そういう内容の業務は自然とconfidentialなものになっているっていう側面はありますよね。まあ、これを秘密主義と言う人はさすがに居ないとは思いますが。(居たらただの世間知らずでしょう。どこの企業が契約内容をべらべら喋ったりしますか、ってことです。)
ですが、そういうことではなくて、コミュニティと連携をとらなければいけない部分で、それがコミュニティ側から見てできていないという部分が不満に思われているのだと私は感じます。
しかし、実際にコンタクトをとる方法を考えてみると、もじら組のようにあいまいであっても組織だっている相手ならコンタクトをとりようがあるものの、それ以外の個別に活動している人にまで行き渡らせようとするとblogのように、不特定多数に向けたコミュニケーションしか無くなるように思えます。
でも、こういう、不特定多数を相手にしたコンテンツというのは、結局「俺はこんな話が聞きたかったんじゃない、期待はずれ」って言う人が絶対出てくるのでその実効性には疑問が残ります。(べつにやることに意義がないなんて言ってる訳ではないです。やらないよりはやった方が良いでしょう。) 結局どこまでいっても、「努力不足」は続く訳ですよ。つまり、自分が満足したい答えが欲しい人っていうのは、Mozilla Japanの関係者と濃密にコミュニケーションをとらないと永遠に文句を言い続けるだけではないかと思います。個別にはその人を説得するための言葉を用意できますが、不特定多数を相手にするとそんなことはできないからです。
と、まあ、普段はできるだけ書かないようにしているMozilla Japan関係の話をあえて書いてみましたが、これ、絶対にMozilla Japanの見解はこうだ、みたいにこのエントリを引用する人が居ると思います。この辺、ちょっと考えてもらえれれば、「俺はどこの社員だ」なんて名乗ってblogなんてやることがどれほど大変か理解できて、実名を書けとは言いませんが、Mozilla Japan の関係者ならそれと分かることを書いて置いて貰いたいと思います．
なんていう無茶は言われないかと思うのですが。
あくまで、この日記は個人的なもので、Mozilla Japanの公式見解を示す場ではありませんので、誤解なきようにお願いします。「でも、Mozilla Japanの中の人の言うことだから、Mozilla Japanの意見に変わりは無い」なんて思う人が居るでしょうけど、そういう人がいるから所属組織がはっきりしていると発言しにくくなるんですよ。
申し訳ないです。完全に「顔が見えない」から「秘密主義」にすり替わってました。
しかし、Piroさんの言うように、例えば Mozilla Fundation の Michel Baker が彼女のブログで語ることでさえこれは Mozilla Fundation の公式見解なんて思ったこと有りません．
と考えてくれる人ばかりではないのです。
ネット上での声の大きさというのは重要なもので、またそういう誤解をする人に限って声が大きいわけです。 更に、悲しいことに、賛同してくれる人が賛同するコメントを付けることは少ないというのが実情です。 結局ネガティブな意見ばかりがネット上では目立つという悪循環に陥りがちです。 当たり前の話なんですけどね。
うちのサーバのログによると、WebStudioに検索エンジンから来る時に最も検索されているキーワードは「all your base are belong to us」。かなり古いネタなのに未だに検索する人が多いというのがスゴい。
ちなみに、私もよくBugzillaで同じミスをやらかしてます。「all」が下手に日本語で常用されているからこういうミスが生まれやすいんでしょうね。
1.8 branchにもチェックイン。1.8.0 branchでの修正も考えた方が良いのだが、正直気は重い。世界中のキーボードレイアウトのキーの組み合わせによる文字入力の一覧表があればこの辺、ハックしやすいのだが。
要約ではJISキーボードに絞っているが、ソースコードを見てると、Win2k/WinXPでは全キーボードレイアウトでバグっているように見える。
とりあえず修正済み。
修正完了。
トリビアな実にマイナーなバグが残っているが、どうしたものか。
今回追加された家計簿自動登録機能は、 Firefoxの拡張機能「Greasemonkey」を用いたもの。Greasemonkeyは、対応したユーザースクリプトをブラウザにインストールすることで、Webサイトの機能やデザインを、ユーザーが自由にカスタマイズできる機能。
(中略)
なおガイアックスによると、「今回の家計簿自動登録機能はFirefoxのGreasemonkeyのみの対応だが、近日中にブックマークレットにも対応予定」とのこと。
Greasemonkeyを利用しているというだけでも斬新なのに、Firefoxのみが先行対応な機能をリリースする、というのにはものすごく驚いた。
散財.comは非常に綺麗なHTML(問題が無いわけでは無いが)なので某SNSとは違ってWeb標準技術に理解というか、興味があるのかな。
少し前からもずはっく日記もRSSでコンテンツの一部も配信するようになったわけですが、この機能追加を行っている時に感じたいくつかの引用に関する問題点。
転載と引用の境界線として、本文と混じらず、引用部分であることが明確であることと、引用元の明示していなければいけない、というのがあります。これらを満たしていないと引用とは認められない訳ですが、HTMLの場合、blockquote要素とそのcite属性を使うことで引用元を明示することができます。(多くのUAはcite属性をレンダリングはしませんが、それはUAの問題であって、コンテンツ作者には責任の無い問題だと思います。意図的に筆者の言葉として誤認させるような構成になってるとまずいでしょうけど。)
RSSで内容を配信するには二つの方法があります。一つはタグを削除してプレーンテキストを配信する方法と、CDATAを利用してタグもテキストの一部として配信してしまう方法です。
ここで、前者の方法をとると、blockquote要素のcite属性が削除されてしまうので、どこからどこまでが引用か不明瞭になる上に、引用元の明示ができずに、条件が満たせず、確実に著作権違反となると思います。本文で引用元を明記していれば問題無いでしょうが、そうではない文章がRSS内にひとつでもあるとアウトでしょう。
で、問題は後者。CDATAでHTMLの断片を入れることで、blockquote要素という情報は残ります。cite属性値にはURIがそのまま残るので、引用元を明示できていると言えるかもしれません。しかし、引用している、また、その引用元であるという意味は、(X)HTMLのblockquote要素と、cite属性が持つものであって、XMLでは当然成り立ちません。CDATAで含まれているソースコードの断片がHTML文書であるということを立証しない限り、引用であると明示できているとは言えない可能性があるわけです。問題のタグがHTMLのものであると立証するには、CDATA内でひとつのHTML文書として、(文書型宣言から始まって)完結していなくてはいけないように思えます。
こういう理屈で考えていくと、文書型宣言の無い怪文書は引用の条件を満たそうとするとblockquote要素に頼らずに自然言語で明言するしかないのかもしれません。
つっこみメールを頂いたので補足。
これらを満たしていないと引用とは認められない訳ですが
というあたりの下りですが、私があげた条件は、必要条件の一部であって、これを守れば十分、という訳ではないです。このトピックは必要条件すら満たせない可能性がある、という話でした。
Gervのblog。確かに、私たちはWin9xのサポートを今すぐ打ち切って、Fx2ではサポートしない方がユーザのためと言えるのかもしれない。
古いOS(セキュリティパッチの出ないOS)を使い続けることは当然、その製品を使うユーザの自由ではあるが、Internetという公共のネットワークにつなぐには適していない。例え、セキュリティホールゼロのブラウザを使っていたとしてもそれは変わらない。
ただ、Fx3がWin9xをサポートしないのは、セキュリティやらなんやらと高説を用意するまでもなく、単にOSの設計が古すぎて新しいgfxのコードがWin9x上では動作しないという技術的問題があるためであるというのが実際の所ではある。
直接聞いた話ではないので一般の人と入手できる情報量は変わらないため、特別新しい話ではないが、ハッカーではなく、テスタ等の協力者のためにthebes等の用語解説も兼ねてGFXまわりの状況について簡単に説明しておく。
まずは従来(Gecko1.8.1以前)の概念は次の図のようになっている。
レイアウトや、描画を指示するコードは概ねXP化されていて、そこからGFXのAPIを使って、GFX経由でOSやツールキット等のネイティブ環境とのやりとりを行っている。しかし、ひとつAPIを変更しようとするだけで全プラットフォームでの変更が必要となるのでとんでもない労力が必要だった。
そこで各プラットフォームとのやりとりをcairoという別のオープンソースプロダクトに任せてしまって、より高性能な描画エンジンの入手と、コード管理の手間を放棄を行おうというのがGecko1.9での構想。
しかし、cairoはCで記述されているため、そのままでは利用しにくい。そこで、thebes(テーベ、古代エジプトの都市、古代ギリシャの都市国家)というC++ラッパーを開発している。
現在のTrunkの設計は次のようになっている。
gfx/src/thebesは従来のgfxのAPIを実装していて、内部ではgfx/thebes以下のthebesを利用しているだけなので、thebesのラッパーと呼べるかもしれない。(この部分も含んでthebesと呼ぶのかどうかは不明。)
実際にcairoのC++ラッパーとしてのコードはgfx/thebes以下にある。cairoそのものがプラットフォームごとにAPIを用意しているのでthebesもそれぞれのプラットフォーム毎に作成されている。(ただ、従来のgfxコードとは違って、そのファイル数は極端に少ない。)このthebesからはcairoを経由せずに、pangoやWin32 APIに直接アクセスしたりもする。そのため、図のように、単純な階層構造にはなっていない。
しかし、レイアウトのコードを中心に見てみると分かるように、パフォーマンスだけではなく、開発効率もこのままでは悪いままなので、次のように変更されていくのではないかと思われる(これは推測)。
つまり、パフォーマンスが要求される局面(テキスト描画等)は、レイアウトコードからダイレクトにthebesにアクセスできるようにして、旧gfxのAPIは整理されるようである。(どのように整理するのかは具体的には決まっていない模様。)つまり、この作業が始まると、non-cairoビルドはできなくなる。
綾川さんのパッチを元にした修正、いつの間にやら1.8 branchへの承認申請がされていて、通ったのでチェックインした。
Linuxの中国語のIMでover-the-spotな表示ができない、というバグ。
変換中に未確定文字列がないIMが存在することをエディタが仮定していなかったのが原因。キャレット位置を未確定文字列が無くても正しく返すように修正することで対応した。
ようやく修正された。これでこの日記のスタイルが、ようやく思い通りに表示されるようになった。
改善されたポイント。
vertical-alignの実装がマトモになっている。opacityに対応している。:hoverでwidth: auto;にした場合、きちんとshrink-to-fitの計算が行われるようになっている。思い通りになっていないポイント。
text-align: justify;ができていない。opacityで半透明になっているボックス上でテキストが欠ける(たぶんクリッピング処理がletter-spacingの追加幅を意識していない)。outlineがボックスの背景と同じスタックに描画される(CSS2.1のoutlineプロパティの定義では問題ないが、Appendix E section 2 step 9には違反。つまり、仕様違反ではないが、非推奨な描画方法をとっている)。last-childセレクタが未実装(CSS3)SVG の専門家のブログみたいです．
Rocがどの程度SVGに関与してるかは私も知らないですが、彼は別にSVGの専門家という訳では無いと思います。
Rocは私が関わってる部分だけでも、旧GFX、content、layout、印刷関係、widget、viewと、かなり広範囲にわたってハックしている人です。ちなみにIME無効化問題で、XP部分の実装最終案はこの人のアイデアです。(私のパッチを元に、よりシンプルで、より効率の良い方法を提案してくれました。)
非常にお世話になってる人ですが、まだ面識が無いんですよね、他の人とも満足にコミュニケーションがとれた訳ではないですが。
Bug-org 340590のregression。
Bug-org 340590で、ビットマップフォントが使えるようにcairo内部でのフォントの扱いを32倍の精度から1倍に落としたことが原因で露呈したバグ。まあ、つまり元々私の作ったletter-spacing、justifiy向けのコードにバグがあったということ。
詳しい説明は省くが、単純に小数点の丸めによる誤差がバグの原因。XPレベルでこの誤差が出ないように修正したので、選択時に文字が揺れるバグも同時に修正されている。(Linuxでも私の環境では修正確認できている。)
------- Comment #116 From Mike Schroepfer 2006-06-22 10:30 PDT [reply] ------- Please nominated appropriate patch(es) for the 1.8.1 branch
どうも、Mike SchroepferはBug-org 287179をFx2.0でも修正したい模様。(ちなみに次のコメントを見るとDavid Baronは反対の模様。)
たしかに、このバグは発生するキーボードレイアウトでは滅茶苦茶重要だとは思うが、そのリスクがかなり大きい。既にTrunkではWin9xサポートが停止した状態でregressionをつぶしていってる訳で、誰がどうやって検証するんだという話になってしまう。もしチェックインされたらBranchを追いかけている方はテストよろしく。
テストのためにキャッシュフォルダを消そうとしてprofileフォルダを消してしまった。しかも、Shift+Delで。
クリーンな環境が手に入ったと、前向きに考えよう……
それにしてもここ最近、変にクラッシュすると、キャッシュフォルダを削除しない限り起動時にクラッシュしたりするのはなんとかならないものか。
現在パッチのテスト中。パッチの最新版はBug-org 255990から直接取得して欲しい。Trunk用なので1.8branchには適用できないかもしれない。
Windowsユーザの場合、自前ビルドできない人も多いと思うので、テストビルドを用意している。新しいパッチを提出したら逐次ファイル名そのままでこのビルドも更新予定。当たり前だが、Trunkビルドなので気軽には使わないように。
もし、今回の修正で崩れるページを発見したら、Bug 1476の方まで報告して欲しい。
「ブラウザ上で「Office 2007 Beta 2」が使えるオンライン体験版公開」とあるが、これって多分ActiveXを使ったものだと思うのだが、そうなら「ブラウザ上で」と書かずに、「IE上で」と書いて欲しいなあ。
ある意味間違ってはないけど、語弊がありすぎる。
修正完了。これで前回のバグともあわせて、署名ファイルにはOSの標準文字コード(日本語版WindowsならShift_JIS)と、UTF-8、UTF-8N、UTF-16(BOM必須、オーダーは不問)となった。
こちらも本家側では同じバグでbug 5130と共に修正。
ただ、その「真剣さ」はどちらかというと、労力の支出を切り詰めて消極的に「益」を増すことに重点を置いたものだと僕には思える。それに対して、営利企業に必要とされている「真剣さ」は、労力の支出を切り詰めることよりもユーザのシェアという収入を増やすことで積極的に「益」を増すことに重点を置くというものなのではないだろうか。どちらも大切な事であるのは当然だけれども、どちらを重視するかという意味で。
字面だけ見ているとなんかズレがあるような気がするのでちょっとだけ。
技術系のコミュニティ(例えばBugzilla-jp)ではそのコミュニティの参加者にとっての「益」とは(その人が協力することによって)バグの無い快適な製品を使えるようになるであるとか、自分の技術、知識の向上であるとかであって、(短い目で見た場合は特に)ユーザのシェアは、直接的な利益とはならない。単なる無関係では無い話なだけである。
目的そのものが違う、技術系コミュニティと営利企業を比較した場合に、消極的
と積極的
という語をそれぞれを端的に表すものとして使うことには違和感がある。あえて、こうした冠をつけるなら、ユーザのシェアを増やすことに対して、「無関心」、「積極的」と言い表す方が現実に即しているかと思う。
技術系コミュニティは自分達の目的には「真剣」だし、「積極的」であると私は思っているし、そう信じたい。
ところで、技術系は特に、不満があれば改善しようとボランティアが立ち上がり、積極的に乗り出す人が居るが、サポート態勢や、態度に不満のある人は、どうして自分でそれを改善しようとしないのだろうか? そのためのコミュニティを誰かが作っても良いのではないかと思う。
それが無い理由としてPiroさんは初心者をサポートするのは大変なことであるという論調のようだが、技術系でコミットすることも決して楽なことではない。テスタ、QAもかなり大変というか面倒な作業だし、パッチを書いて、実際にハックするとなると、更に厳しくなる。もちろん、意見の対立や、運営の問題など、普通に人間関係の対応の問題も常につきまとう。おまけに、本家が英語なので場合によっては英語で喧嘩することがあるのだが、これは言いたいことがなかなか言えないので非常にストレスが溜まる。つまり、大変さ、という点では何ら差は無いように思う。では、いったいこの違いは何なのだろうか?
技術系のコミュニティに何故居られるかと聞かれたら、職業と化した今を含めても「好きだから」と言える。サポート等に関しては、不満はあっても「好きだ」と言える人が居ないのかもしれない。だとしたら、世の中のサポートセンターの人はみんな金のためだけに仕方なく働いているのだろうか? そうは考えたく無いし、また、もじら組フォーラムで、過去ログに無いケースを検証、解説してサポートしている人は居るのだから、単に技術系ケースよりも(その需要に対して)少ないだけなのかもしれない。
大阪に住んでた時の近所の薬局(利用経験あり)で凄惨な事件があったようで、かなり凹み。
せっかく教えてもらったし Screenshot も撮ったので、bug-217895 として報告しておいた。9.01 で直れば良いな。直ったとしたら中野さんのおかげです。
それは違う。もし修正されたら、saitonさんのおかげである。
私はOpera社の手順には従わずに愚痴を書いただけで、教えたつもりも無い。情報をWeb上から見つけ出して、きちんとしたバグ報告という形でフィードバックしたsaitonさんの行動の方が重要だ。saitonさんがそうして積極的にコミットしているのであれば、私の愚痴が無ければ単に別のバグの報告に時間を割いていた可能性もある。
ネット上で不具合を書くだけならどんなに開発能力の無い人間でもできるが、有益なバグ報告にはその能力と、そのプロダクトへの愛情が要求される。saitonさんは今回、Linuxでは再現しないことを確認している。これは開発者にとって非常に大きなヒントとなる。再現条件の絞り込みは原因となるコードを絞り込むのと同義なので、非常に重要な行動だ。
ちなみに私も以前はOperaのバグを報告したことがあるが、bugzillaと違って全く何の応答もなく、修正されたかどうかの確認も新しいバージョンをダウンロードして自分で確認しないといけないという体制が非常に気に入らないので辞めてしまった。Operaのエンジンのバグを見ていると、テスト不足というより、テスタ不足の印象を受ける。このへんの問題を改善してテスタを増やすと非常に良いエンジンになる可能性が高いと思う。