CLOSED
初回投稿日時: 2005年08月02日04時13分42秒
カテゴリ: Mozilla Core
固定リンク: id=2005080200
SNS:
Tweet (list)
チェックインにいよいよ本格的な制限がかかった。
この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
チェックインにいよいよ本格的な制限がかかった。
なんでか、再度、オープンされた。はて?
nsFieldSetFrameのreflow時のミスなのは明白だったので、修正にチャレンジ。 David Baronから何度もパッチを却下されたが、修正完了。
他に告知するところが無いので……(もじら組トップページに情報出すべきだと思うんだが)
bugzilla.mozilla.gr.jpサーバ、ダウンしています。復旧予定は私も知りません。
ようやく復旧。そして、バージョンアップされました(たぶん)。 関係者の方々、お疲れ様です。ありがとうございました。
Win95日本語版でのみ、クラッシュするという問題。VYV03354さんが修正してくれた。
詳しい理屈等は不明。私にはパッチを理解できない。
修正完了。単に、ブックマークを読み込む際に、METAの文字コード宣言で、エイリアスを許可していなかったのが問題。エイリアスでも正しく文字コードを判定できるように修正した。
ついに修正された。メモリリークの副作用があるようだが、既にパッチは出ている。とりあえず、かなり快適だ。
こちらもbug 1350の修正によって、自然消滅。
メニュー内でホイールを回しても、微妙にスクロールしなくなった。前々から気になっていたのだが、ようやく修正されたのか?
見た目は3Dなので目新しさというか、インパクトがあるのだが、個人的に3Dのゲームが苦手なこともあって、3Dは2Dの表示デバイス(&入力デバイス)での利用には限界というか、壁があるように思う。
ドローツールとタブレットで絵は簡単に描けても、ポリゴンのモデリングはそうはいかない。でも粘土細工なら誰でも出来るだろう。そういうこと。
明瞭で応答の速い3Dの表示デバイスがあって、画期的な使いやすい3Dの入力デバイス —例えば映画JMの様な— があれば実用度は上がるだろうが、それでも現在のHTMLの手軽さに比べて、制作が困難になる、という致命的な問題が最後には立ちはだかるんだろう。
最初のパッチから数えると4ヶ月半かかってようやくチェックインしたのだが、ThunderbirdをVC6でビルドした場合にリンクに失敗するという問題が発生。今のところ原因は不明。
gkwidget.lib(nsWindow.obj) : error LNK2005: _IID_IAccessible already defined in gkwidget.lib(nsWinWidgetFactory.obj) gkwidget.lib(nsWindow.obj) : error LNK2005: _LIBID_Accessibility already defined in gkwidget.lib(nsWinWidgetFactory.obj) gkwidget.lib(nsFilePicker.obj) : error LNK2005: _IID_IAccessible already defined in gkwidget.lib(nsWinWidgetFactory.obj) gkwidget.lib(nsFilePicker.obj) : error LNK2005: _LIBID_Accessibility already defined in gkwidget.lib(nsWinWidgetFactory.obj) gkwidget.lib(nsToolkit.obj) : error LNK2005: _IID_IAccessible already defined in gkwidget.lib(nsWinWidgetFactory.obj) gkwidget.lib(nsToolkit.obj) : error LNK2005: _LIBID_Accessibility already defined in gkwidget.lib(nsWinWidgetFactory.obj) gkwidget.lib(nsLookAndFeel.obj) : error LNK2005: _IID_IAccessible already defined in gkwidget.lib(nsWinWidgetFactory.obj) gkwidget.lib(nsLookAndFeel.obj) : error LNK2005: _LIBID_Accessibility already defined in gkwidget.lib(nsWinWidgetFactory.obj) gkwidget.lib(nsNativeDragTarget.obj) : error LNK2005: _IID_IAccessible already defined in gkwidget.lib(nsWinWidgetFactory.obj) gkwidget.lib(nsNativeDragTarget.obj) : error LNK2005: _LIBID_Accessibility already defined in gkwidget.lib(nsWinWidgetFactory.obj) thunderbird.exe : fatal error LNK1169: one or more multiply defined symbols found
というエラーメッセージなので、OLEACC.HがnsWindow.h経由で読み込まれたオブジェクトファイル同士をリンクさせる時にエラーが出ているようなのだが、こんなところ、私のパッチでは変更していない。VC6のバグなんだろうか?(.net以降ではこの問題は発生しない)
トリプルクリックした場合は、行ではなく、段落を選択すべき、という要望。修正されている。
UIにまでRSSという仕様名を出すべきではないと私も思う。誰もブラウザをCSSレンダラとか呼ばない様に、だ。
将来、RSSにかわる仕様が登場した時に、可能ならRSSと同じ名称、UIでそれに対応することが望ましい。そういう意味でも合理的な話だ。
もっとも、「Webフィードを作るにはRSSで記述します」という説明をすべきところ、あくまで「Webフィード」の作成の仕方、ということでRSSの名前を伏せて説明するようなことがあるべきではないとは思う。
コンテンツの作成者はRSSという名前で認知するべきだが、これが利用者にまで広がる必要は無いというのが私の考え。
ようやく修正された模様。今のところ、新たな再現手段は見つけていない。
Mozilla系のアプリ同士、プロセスをまたいでドラッグ&ドロップするとドラッグ元のアプリケーションがクラッシュしていたバグ。修正された。
これも修正された模様。元々、確実に再現する条件が分からなかったので確信は無いが、確かに今のところ偶発的に発生していない。
不安定すぎて使い物にならない。何のバグのregressionだろうか。
SNS内の文書はご存じの通り、その会員以外には見えないし、そのことを前提に日記を書いている人も多いのではないかと思う。
では、ここから通常の公開されているWebページに引用することは許されるのだろうか?
法的には引用の条件を満たしている限り(転載ではない限り)問題ないように思えるが、道義的にはどうなのだろうか。一般的にプライベートでやりとりしたメールの内容を公開すべきではないわけだが、この問題はこれに近いように思える。
かといって、自分の文書に対して批判的な内容をSNS内で公開された場合、これに反論したくなるかもしれない。また、逆に、素晴らしいコメントがついたので紹介したくなるかもしれない。しかし、これらを引用してのコメントはそのSNS内でなければ許されないのだろうか? もしそうなら、消化不良で何か気持ち悪い。かといって、SNSに場を移して議論を続けるという選択肢は、議論が分散してしまうし、元々一般公開された文書でのみ追いかけていた人には置いてけぼりを食らわせてしまうので論外だ。
メールのように引用する前に相手の了解をとれば良いのは確かだが、もし自分に批判的な相手だった場合、そこまでするのも難しいように思える(気分的に)。相手に悪意というか敵意のようなものが感じられる場合は特にそうだろう。
みなさんはどのようにお考えだろうか。
先日のトピックにmixiからリンクがありますが、これとは関係ありません。あれは好意的なコメントでした。
ようやく修正完了。関連する環境でのビルドには一通り成功したようだ。(Portsは知らない)
いよいよ次のステップに進める。Windowsユーザは期待して待っていて欲しい。
また、IME APIのインターフェースは仕様がこれで固まったのでLinuxやMacでのサポートを改善できる方の協力を待っている。腕に自信のある方は是非、名乗りを上げて欲しい。
とりあえずパッチのできは良好。あとはMacでの動作確認が欲しいのと、UTF-8を標準としているFedoraでのテスト。共に、SuiteかThunderbirdをビルドしないとテストできないので、協力してもらえる方は注意を。
高校野球が終わったので、ようやくうちのRD-XS41でジャストクロックが動いてくれた。ジャストクロックに甘えているのか、かなり精度の低い時計なのでかなり迷惑だった……。アバンタイトルが半分ぐらい切れたりとかってのはさすがに辛い。
ようやくtoolkitにも修正パッチを投入できたのでFirefox/Thunderbirdでも修正できているだろう。 現在1.8 Branchへのチェックイン承認待ち。
1.8 Branchにもチェックインした。
これもようやく修正された。
久しぶりの徹夜で疲れた。だが、なかなか完璧にパッチが完成。興味のある人は本家(注: 本家ではBug-org 55751で進めている)に提出しているパッチをテストしてみて欲しい。ただし、IME APIの実装状況上、Windowsでしか機能しないことに注意。
パッチには若干気に入らないところもあるが、指摘されなければそのままにしておこう。
ついに修正完了。長かった。
長いURLのmailtoからメーラを起動できない問題。どうやらMozillaのバグではなく、Windows API(ShellExecute)のバグのようで、これ以上長いURLをそのAPIに渡すとクラッシュするらしい。別のバグで意図的に制限されたものなのでこれは修正できない。
FAYT再設計時の設計ミス。Trunkでは修正が完了した。
個人的に非常に気になっていたバグ。ようやく修正できた。ちなみにこれは再設計時のregressionではないと思う。
現在のパッチではFlashのエディタでIMEが使えなくなることが判明。一応、最悪の場合のための簡単な回避策は見つけているが、これだとIMEのツールバーやアイコンがちらつく問題があるので、できればよりよい解決策を見つけたい。
まだ本家はfixedになっていないが、当初の問題であるFirefoxのFAYTでのエラー発生は解消されている。
CSS3の:disabledと:enabled疑似クラスがサポートされた。1.8ブランチへはこれから承認申請の模様。