この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

もずはっく日記(2005年11月)

2005年11月1日

Bug 4697 [FAYT][Find in This Page][bfcache] フレームページで検索した後、ブックマークで別のページに移動して検索すると、検索が機能しない #2 初回投稿日時: 2005年11月01日05時14分02秒
カテゴリ: Mozilla Core
固定リンク: id=2005110100
リンク元: 0件
SNS: (list)

どうやら、bfcacheに大きなバグがある模様。bfcacheが非表示になったページのオブジェクトを参照したままになっているのはバグのようだ。どうも、フレームのようなサブドキュメントが解放できていないらしい。(親ドキュメントのみが解放されている。)デバッグ実行でもそれが確認できている。Borisは1.8リリース前に修正しないとヤバイと言っているが、どうなることやら。

リリース日を優先するか、クオリティを優先するか、Mozilla Foundationの判断はどちらになるやら。

2005年11月2日

Bug 4701 [Find Toolbar][FAYT][Find in This Page] findBar.js内の関数/変数の非グローバル化 初回投稿日時: 2005年11月02日02時51分21秒
最終更新日時: 2005年11月02日02時53分26秒
カテゴリ: Firefox
固定リンク: id=2005110201
リンク元: 1件
SNS: (list)

パッチがfindBar.js全行に絡むため、直接交渉の結果、即決で修正完了。(途中で、別のパッチが混入すると一から作業やり直しになるため。)

あまり十分にテストできたとは言えないので、明日のNightlyビルドでブラウザの機能が途中でキャンセルされているような症状を見つけたらバグ報告して欲しい。多分、このバグのregressionだ。(レビュー完了前のパッチでは、タブの切り替え処理が途中でエラーとなり、全て走らなかったバグがあった。)

ちなみに、この修正で早くも1.8 BranchとTrunkの検索周りのコードに互換性は無くなった。

2005年11月3日

Acid2テストに合格することに意味があるのか 初回投稿日時: 2005年11月03日00時25分41秒
最終更新日時: 2005年11月03日00時48分43秒
カテゴリ: CSS Opera
固定リンク: id=2005110300
リンク元: 17件
SNS: (list)

Operaは未だにvertical-alignという基本的なCSSプロパティの解釈が実にバギー。 CSSマニアックスという感じのタイトルが似合う、非常に非現実的なコンテンツの表示テストに合格するよりも、一般的に使用頻度の高いCSSのバグ修正を優先すべきだ。(Acid2テストではvertical-alignはbottom値しかテストされない。)

こんな指標があるなら、各社がマーケティング上のアピールの為にこれに絡むバグを優先的に修正するのは当然、想定できたはずだ。結果としてそれは良い方向に進んでいるのだろうか? 私はそうは思えない。

WaSPが業界全体の限られたリソースをこんなテストの修正に向かわせた責任は大きいと思う。どうせなら、もっと現実に則したテストを作るべきだったはずだ。どんな文書でも絶対にと言って良いほど使われているtext-decorationすら、全くテストされていないというのは納得できない。

2005年11月4日

Bug 4708 Find Toolbar無しでFAYTできるようにして欲しい 初回投稿日時: 2005年11月04日02時19分54秒
最終更新日時: 2005年11月04日06時30分40秒
カテゴリ: Firefox
固定リンク: id=2005110400
リンク元: 2件
SNS: (list)

FAYTの時に、Find Toolbarを非表示のままで検索できるようにしてほしいという要望。 当初、FAYTを無効にするオプション追加の要望かと思って請け負ったのだが、コメントを見ていておかしいことに気づいた。

Find Toolbarのエディタが無いと、当然IMEは動かない。また、キーボードレイアウトによってはキー入力から文字を合成しなくてはいけなくなる(アクセント記号が絡んだ場合や、タイ語もかな?)。こんなことはJavascript上では不可能だ。(こんなもの、OSレベルでやるべき話である。)

結果、wontfixとしたが、やっぱりASCIIな人から、なんでやねん、というコメントが付いていた。一応、他言語の処理についても簡単に説明を書いておいたし、Mike Connorがverifiedとしてくれたので一応決着。

やっぱり、猛烈に反論が出てきてる。でも、現在のコードすら見たこと無い、建設的ではない一方的な要望ばかり。SeaMonkeyから移植した当時はちゃんと動いてたじゃないかなんて言う始末。SeaMonkeyのFAYTのIME処理なんていい加減きわまりない。幸せだったのは、一部のロケールの人だけだったという自覚も無いようで。

開発者のコミュニティに要望を書くときは、技術的に筋の通った詳細な案も共に出さなくてはいけないと思うのだが、世間ではそうではないらしい(笑)

地震速報 初回投稿日時: 2005年11月04日03時43分52秒
カテゴリ: Anime
固定リンク: id=2005110402
リンク元: 0件
SNS: (list)

ローゼンメイデン・トロイメントの第一話(BS-i)に字幕スーパーで多々、地震速報が混入。しかも嫌がらせのように、更新間隔が短く同じ情報を何度も流すし、Bパートに入っても流し直すし。勘弁してくれ。前作をDVDで買ってないので、今回も買う気は無いのでキャプチャしてたのに。

ちなみに、TMPGEncによるMPEG2エンコード時間が最短1時間40分だったのが、同じ条件で50分に短縮できている。素晴らしい。

2005年11月5日

スラド関連いろいろ。 初回投稿日時: 2005年11月05日05時58分42秒
最終更新日時: 2005年11月05日05時59分59秒
カテゴリ: 雑談
固定リンク: id=2005110500
リンク元: 0件
SNS: (list)

スラドのコメントからリンク張られてた文書ですが、あまりにアレで、数時間かけて読んでしまいました。

韓国は“なぜ”反日か?

中国・韓国・北朝鮮関係の一連の問題って、向こう側の戦略として文句言ってるんだから、言わせときゃええやんって感じだったんですが、このリンク先の三つ目のドキュメントは本当の話なら恐ろしいことです。ってか、在日って税金納めなくても、生活保障されてるってどういうことよ。私なんて去年は所得はゼロ円でしたけど、何か?

そういやスラドと言えば、アニメータの平均給与の話がありましたが、少ないですねぇ。私も同じように好きなことを仕事にしててこれよりは年収が上になりそうなので、幸せといえば幸せなのかなぁ。まあ、この手の話が出てくると、なんでも趣味でやってる内が丁度良いもんだと思います、本当に。

愚痴ついでに、バグ(要望含む)をinvalidwontfixにするという作業はバグを修正するより大変なことなんだと改めて認識させられました。無責任に要望書くのはやめてください、本当に。

2005年11月8日

疲れた。 初回投稿日時: 2005年11月08日07時31分23秒
カテゴリ: 雑談
固定リンク: id=2005110800
リンク元: 0件
SNS: (list)

今日だけで、四つのパッチを提出してる。なんでだろう。とりあえず疲れたので寝る。

2005年11月12日

Bug 1363 IMEがONの時、ショートカットキーが文字入力に使うキーだと機能しなくなる(スペースキーでスクロールできない/メーラでF,N,T,B,Pが効かない) #5 初回投稿日時: 2005年11月12日06時30分42秒
カテゴリ: Mozilla Core
固定リンク: id=2005111200
リンク元: 0件
SNS: (list)

新設計のパッチが概ね完成。しかし、またしてもSeaMonkeyのFAYTが障害に。とりあえず、フレームじゃないページなら、概ねFAYTも動くようにはなってきてるものの、フレームをまたいで検索する時の処理が元々おかしいようで、選択色がシステム標準のものに戻ってしまう(このタイミングでFAYTの入力受付終了とするしかないので、非常に辛い状況)。細かいバグは無視して行って、後でリファクタリングする方が良いかもしんない。

2005年11月13日

Bugzilla-jp荒らし 初回投稿日時: 2005年11月13日10時54分03秒
最終更新日時: 2005年11月13日11時34分40秒
カテゴリ: 雑談
固定リンク: id=2005111300
リンク元: 10件
SNS: (list)

昨日未明から、突然あるアカウントがスタッフ(私)の警告を無視して、適切に変更していたステータス等の情報を勝手に(しかも多くの場合、変更理由も書かずに)書き換えるという荒らし行為が多発した。現在、該当のアカウントは利用停止措置の対象となったが、どうも同一人物が新たにアカウントを取り直して活動を継続しているように見える(本人は気づいていないようだが、文章の癖が非常に似ている)。ちなみに、どちらのアカウントにもメールを出したが、何の返事も無い。特に、同一人物では無いですか?とストレートに問い合わせた、後者へのメールにまで返事が無いというのはおかしい。違うなら反論するだろう。

ちなみに荒らしのあったバグはBug 4731である。バグの動きを見てもらえれればいかに、ひどいか分かる。私は当時、IME無効化のパッチの作成とテストを繰り返していたが、02時37分51秒からはじまった、荒らしにより、少なくとも03時10分46秒まで、この荒らしのために仕事にならなかった。(実際にはその後も対応策を検討したりして、もっと時間が奪われている。これはMozilla Japanの仕事として活動している身からすると実際に損害が出てしまっていることを意味する。)

また、該当の報告者は、comment 6で次のように臆面もなく言い放っている。

Safeモードに切替える方法と
Nightlyビルド方法を記述した
日本語説明のURLを示して下さい

これが開発現場で発言する内容だろうか?

ちなみに、バグ報告ガイドラインには次のように書いてある。

次に、必ずそのバグを三日以内にビルドリリースされた物を使って再現してください。私達の開発プロセスはものすごく速く進んでいるため、あなたが見つけたバグはすでに修正されているかもしれないからです。(ナイトリービルドは mozilla.org バイナリページからダウンロードすることができます。)

バグを報告するにあたって、Nightlyビルドでのテストは必須となっているし、ダウンロード先も明記されている。つまり、バグ報告をする人間にとっては常識でなければいけない部分がまず欠落している。

で、結局私も感情的になってきて以下のようにコメントを追加した。

ステータスを勝手に変更するな、と言っているでしょう?
これ以上、「荒らし」行為を続けないでください。

この発言(03時02分)の後、まだそれでもステータスを一度修正しに来たが、それも再度修正しなおすと、反応が無くなった。

当然、ピンと来る。こんな奇妙な行動をとる人が次にやりそうなこと、2ちゃんねるかどこかのBBSで自分の正当性をアピールしようとするのではないだろうかと。実際、すぐ(03時06分16秒)にそうなった。

663 :名無しさん@お腹いっぱい。:2005/11/12(土) 03:06:16 ID:I62aI0DJ0
こんな報告が出ています
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4731

664 :名無しさん@お腹いっぱい。:2005/11/12(土) 03:19:50 ID:I62aI0DJ0
そのREMINDって何だろう
http://bugzilla.mozilla.gr.jp/bug_status.html

665 :名無しさん@お腹いっぱい。:2005/11/12(土) 03:24:46 ID:I62aI0DJ0
以前はターゲットマイルストーン項目に
Firefox 1.0 があったのに消去されている


666 :名無しさん@お腹いっぱい。:2005/11/12(土) 03:30:06 ID:I62aI0DJ0
添付のスクリーンショット画像では
実際にそうなる場合があるらしい

667 :名無しさん@お腹いっぱい。:2005/11/12(土) 03:32:42 ID:I62aI0DJ0
いづれ Firefox 1.0.7 は使われなくなるでしょう
Firefox 1.5 のリリースが始まりそうだからね

671 :名無しさん@お腹いっぱい。:2005/11/12(土) 03:49:53 ID:15sA9V3l0
独り言はよそでやってろ>ID:I62aI0DJ0

もはや、憐れだ。(ちなみにこれ以降もIDを変えているが、この人のみがageている上に文面も似たようなもので、他の住人から突っ込みを受けている。どうやら、どこを利用するにもいきなり手を出して失敗するタイプの人のようだ。)


しかし、私たちにも反省すべき点がある。ドキュメントの散在、現在の運用にそぐわないドキュメントの放置。だが、これまでの普通の協力者の方々は、bugzilla-jpのスタッフの行動を見て、あわせていてくれていたから問題なかった。(これはすごく運の良かったことなのかもしれないし、その人達の協力のおかげで現在の製品のクオリティは確実に上がっているのだから感謝してもしきれないものがある。)

今回の荒らしも私たちに運用の厳格化、ドキュメント整備の加速を促した点では貢献したと言えるかもしれない。だが、今後も継続して別アカウントで似たようなことを繰り返すのであれば次のGecko 1.9(Firefox 3.0?)のクオリティは確実に本来のものより下がるだろう。これは誰にとっても不幸なことだ。

ところで、この人(達?)に共通する点は何かと考えてみると、開発者を便利な駒として考えているのではないだろうかという点だ。もじら組BBSでもBugzilla-jpで軽く聞いてみたという発言があったことからそう思う。(本家bugzillaも含め)Mozilla界隈でこれほど無礼な人は今まで見たことがない。

2005年11月15日

Bug 1363 IMEがONの時、ショートカットキーが文字入力に使うキーだと機能しなくなる(スペースキーでスクロールできない/メーラでF,N,T,B,Pが効かない) #6 初回投稿日時: 2005年11月15日02時23分21秒
カテゴリ: Mozilla Core
固定リンク: id=2005111500
リンク元: 0件
SNS: (list)

SeaMonkeyのFAYTは見捨てる?という話も出てきた。Find Toolbarを移植できれば問題は全て解決できるのだが、まだ、FirefoxのFind Toolbarも非常にバギーなので私は現時点では移植したくない(同じ修正を二重にレビューして、チェックインするなんてやってらんない。ちなみに、ブランチの修正はこれに近い、結構な重労働)。

SeaMonkeyをtoolkitベースで作り直してくれれば誰もが幸せになるのだが、そういう話は見ないからなぁ。

Bug 1363 IMEがONの時、ショートカットキーが文字入力に使うキーだと機能しなくなる(スペースキーでスクロールできない/メーラでF,N,T,B,Pが効かない) #7 初回投稿日時: 2005年11月15日07時16分56秒
最終更新日時: 2005年11月15日13時16分40秒
カテゴリ: Firefox Mozilla Core Suite Thunderbird
固定リンク: id=2005111501
リンク元: 5件
SNS: (list)

ついに修正完了!!(現時点では、まだ全環境でのビルドに成功してないけど)

結局、SeaMonkeyではFAYTでIMEが使えなくなった。その理由は、

  • SeaMonkeyのためだけにコアに不要なメソッドを追加したくない
  • Gecko1.9がリリースされるまでまだ一年はある
  • FirefoxのFAYTを移植すればすむので、なんとかなるだろう

ということ。ただし、FirefoxのFAYTもまだ大量に細かいバグを持っているため、これの修正が終わってから作業に入ることになる。申し訳ないが、SeaMonkeyのTrunkユーザはしばらく我慢して欲しい(どうしても我慢できなければ、コードを書いて欲しい。Firefoxに原型があるのだから、一から作るわけではない。その場合は最大限、サポートさせてもらうつもりだ。私のFAYT向けの仕事は確実に増えることになるが、それを理由に断ることは無い。)

IME APIがこれで完全にフリーズしたので、Mac/Camino/Photon/Xlib/GTK/GTK2/BeOSでこれに対応するためにIME制御のコードを書くだけで、他のOSも問題が修正される。是非、力を貸して欲しい。

ひとつだけテストして欲しいことがある。Geckoを使ったコンポーネントブラウザのIME制御をこのバグの修正で駄目にしてしまっている可能性がある。(例えばURLバーでIMEが有効にできない等)

今現在、テストする手段が分からないので誰かテスト、もしくは情報をフィードバックして欲しい。よろしく。

VC6でビルドに失敗したので一時的にバックアウトした。現在、再チェックインの準備中。

パッチを少し手直しして、VMWare上のVC6で確認してから再チェックイン。

完全に終了!

2005年11月18日

Bug 4762 embed要素でロードされたプラグインで、IMEが有効にならない。 初回投稿日時: 2005年11月18日00時33分16秒
カテゴリ: Mozilla Core
固定リンク: id=2005111800
リンク元: 0件
SNS: (list)

予想通り、色々とregressionが報告されている。報告してくれている上に、修正案の提示や、パッチのテストまでやってくれているえむけいさんに感謝。とりあえず、イージーミスだったこのバグは修正完了。

Bug 4753 MFCEmbedのURLバーでIMEが無効のままになる 初回投稿日時: 2005年11月18日02時50分43秒
カテゴリ: Mozilla Core
固定リンク: id=2005111801
リンク元: 0件
SNS: (list)

えむけいさんが確認、修正してくれた。さんくす!!

私は無効化にはWINNLSEnableIMEを使っていたのだが、これはWin3.x時代に使われていた廃止されたAPI。MSDNからも削除されていたのだが(つまり今となっては隠しAPI)、私が他にIMEを無効化するAPIを知らなかったことと、DelphiのVCLがこれを利用していたことが、このAPIを使う理由になっていた。

えむけいさんによると、ImmAssociateContextで代用できるとのこと。このAPIそのものの存在は知っていたが、MSDNの説明を見てもその使い道を理解できていなかった。コンテキストの関連づけを解除するということが、IMEを利用できなくなる、ということだったわけだ。

VCLがこの廃止されたAPIを使い続けている理由はなんだろうか? ImmAssociateContextだと、Windowsの特定のバージョンでは問題がある、とかいうのでなければ良いのだが。

ちなみに、WINNLSEnableIMEは引数にウインドウハンドルを持っているが、えむけいさんの情報によると、ウインドウ単位ではなく、プロセス単位でIMEをコントロールしているらしい。どおりで、デバッグ中に、私の意図通りに動いていなかった訳だ。(今思えば、コモンダイアログで期待通りの挙動にならなかった時点で気づくべきだった。)まだまだ勉強と洞察力が足りないなぁと反省させられた。

2005年11月20日

Bug 4773 nsIKBStateControlをnsIWidgetから取得できたか確認するのにNS_ENSURE_TRUEを使うべきではない 初回投稿日時: 2005年11月20日03時24分39秒
カテゴリ: Mozilla Core
固定リンク: id=2005112001
リンク元: 0件
SNS: (list)

IME無効化のコードのバグ。NS_ENSURE_TRUEはコーディング時に想定できない失敗時に利用するものだが、GTK2等の特定のツールキット/OS上では、失敗することが正常なのにこれを使っていたため、デバッグメッセージがすごいことになっていたバグ。こちらも修正完了。

IME無効化に関する問題はこれで一通り解決かな?

SeaMonkeyの件は本家でもめている。 とりあえず、SeaMonkey関係者はFirefoxのFind Toolbarが嫌いらしい。 代替案でなおかつシンプルなものを検討中。 しかし、英語での喧嘩は疲れる。

もじら組のフォーラム(BBS)のあの人は 初回投稿日時: 2005年11月20日04時59分23秒
カテゴリ: 雑談
固定リンク: id=2005112003
リンク元: 0件
SNS: (list)

どう見ても同一人物だよなぁ。

2005年11月21日

Bug-org 283134 rectangles around selected text 初回投稿日時: 2005年11月21日11時06分35秒
最終更新日時: 2005年11月21日11時08分29秒
カテゴリ: Memo Mozilla Core
固定リンク: id=2005112100
リンク元: 0件
SNS: (list)

WinCE上のMinimoで文字を選択すると表示がおかしくなるんで、レビューを頼まれたバグ。 結局、WinCE固有のレイヤーがあったようで、そこのバグの模様。WinCEの場合、

  1. XPコード
  2. Windowsコード
  3. wince/shuntコード

という階層構造になってるんですな。初めて知った。

Bug 1540 IMEの未確定文字の反転はシステムカラー(選択色)を使うべき(エディタの背景色にあわせて、必要なら反転もさせるべき) #3 初回投稿日時: 2005年11月21日11時16分23秒
カテゴリ: Mozilla Core
固定リンク: id=2005112101
リンク元: 7件
SNS: (list)

IMEのもう一つの大きなバグだった、描画色の問題がようやく修正できた。結果、準備にかかったコーディング量から考えると、IME無効化よりもよほど巨大な修正になってしまった。

Windowsの場合、下線のスタイルが実線なぐらいで、他はIEの仕様に概ねあわせてある。 Macは特殊な配色なので、固有の指定を行っているが、他のOS/ツールキット上ではWinと同様の表示になるようにしている。とりあえず、他のOSの文化というか、配色をどうすべきかが分からなかったのでそうしているだけなので、違和感を感じたらバグ報告して欲しい。

一応、特殊色(前景色と同じものを使うとか、40%の色を使うとか、透明にするとか)以外ならprefで変更可能。詳しくはnsXPLookAndFeelのコードを参考にして欲しい。あえて説明しない。

2005年11月23日

Bug 1540 IMEの未確定文字の反転はシステムカラー(選択色)を使うべき(エディタの背景色にあわせて、必要なら反転もさせるべき)で、なぜ下線の色を見やすかった赤からテキスト色に変更したのか(Mac以外の場合) 初回投稿日時: 2005年11月23日02時20分02秒
カテゴリ: Mozilla Core
固定リンク: id=2005112300
リンク元: 3件
SNS: (list)

質問やら苦情やら来そうなのであらかじめ書いておくことにする。なお、Windows以外のプラットフォームに関しては先日書いたとおり、Windowsにとりあえずあわせているだけである。

さて、Windows上で赤線を止めた理由は二つある。

一つ目の理由。IMEの未確定文字列を独自描画するアプリケーション(通常は、IME自身に未確定文字列の描画を任せる)と言えば、大抵、Microsoft製のもので、代表的なものにワードパッド、IE、Office製品等がある。これらの製品、それぞれで未確定文字列の表現方法がまたバラバラだ。これは一社の製品としてどうかとは思うが、MS社員ではないのでそれは置いておこう。で、この中でMozilla Japanのプロダクト最大の対抗馬、つまり乗り換えてもらいたい元の製品といえば当然、IEである。IEユーザが移行する時に違和感が無い、というのはプロダクトのひとつの戦略として有効なのでIEの表示にあわせたというのが一つ目の理由である。

二つめの理由。もし、テキスト色と関係ない色を前景の一部である下線に利用すると、背景色とのコントラストが保たれる保証が無い、という点である。たとえば、赤い背景色のエディタの上で未確定文字列を表示した場合、赤い下線が明確には見えなくなる。背景色は推測できているので、背景色が赤い場合には下線の色を別の色で置き換えるというアイデアもあるだろうが、それは難しい。代替色として素直に思いつくのは色空間の中で、中心点を挟んで反対の位置にある色である。Invertと同じ理屈だ。だが、このバグの当初指摘された問題を見ると分かるように、色空間の中心点に近い色の反対色は、元の色に似ているという問題がある。(この説明が分かりにくいなら、直線を思い浮かべて見ると良い。直線の両端を白と黒とすると、この直線はグレースケールを表現できる。中心が50%のグレーということだ。ここで、49%のグレーについて考えてみると、これの反対色は中心、50%から1%逆方向にずれた色になる。つまり、49%グレーの反対色は51%グレーだ。これは人間の目にはほぼ同じ色に見えることが分かるだろう。)これはどのような色空間を用いても解決できない。反対の色を使おう、というアイデアそのものに問題があるからである。

ちなみにIEでは下線を破線で表現している。これは現状でも太さの制限を考えなければ破線で行えるのだが、WindowsのGDIの昔からある問題で、太い破線を描画するには自前で描画しなくてはいけない。そこで、これはtext-decorationのCSS3対応が終わってから改善することにした。つまり先送りしているだけで構想はあることに注意して欲しい。

2005年11月26日

Bug 4810 iframe(内)を選択してそれを印刷できない 初回投稿日時: 2005年11月26日00時29分15秒
カテゴリ: Mozilla Core
固定リンク: id=2005112600
リンク元: 0件
SNS: (list)

Regression出してしまった。1.8branchでも再現するので注意。 パッチは既に提出しているが重大な問題ではないため1.8finalには入らない予定。(1.8.1?)

iframeを選択、またはifram内の文字列を選択して、選択した部分のみを印刷しようとしても進捗ダイアログは出るものの、進行しない(フリーズするわけではない)。

対応策は、iframeをShow Only This Frameで単体表示して希望の操作をすることのみ。

HTMLエディタでIMEを使うと 初回投稿日時: 2005年11月26日04時37分52秒
カテゴリ: Mozilla Core
固定リンク: id=2005112604
リンク元: 0件
SNS: (list)

Thunderbirdのメールのコンポーザもそうだが、HTMLエディタ上のノードの末尾(行末とか)でIMEを使って未確定文字列を入力できるところまでは良いんだが、変換するとNS_ASSERTIONにひっかかる。HTMLエディタのクラッシュバグとかにつながってないのかな。Thunderbirdでメール作成中にクラッシュしたら、talkbackを送信して、そのIDと共にバグ報告してみて欲しい。

Firefox1.5リリース後に期待していること 初回投稿日時: 2005年11月26日04時39分41秒
カテゴリ: Firefox 雑談
固定リンク: id=2005112605
リンク元: 2件
SNS: (list)

日本語のサイトでもtext-align: justify;を使うサイトが増えて欲しい。自分で修正しておいてなんだが、この修正が一番のお気に入り。

2005年11月27日

Bug 4807 HTMLエディタ上で文字列を選択せずに再変換を行うとキャレット直後の文字が削除される 初回投稿日時: 2005年11月27日08時26分05秒
カテゴリ: Mozilla Core Thunderbird
固定リンク: id=2005112700
リンク元: 0件
SNS: (list)

Thunderbirdのコンポーザのメール本文の部分が(Plaintextモードでも)HTMLエディタなのだが、そこで文字列を選択せずに再変換を行うと、Deleteキーを押したのと同じことが発生していたというバグ。

もともと、bug 4436の原因をMiharaさんが再変換処理にあることを突き止めてくれたことで発覚した。

このバグを修正したことで、bug 4436も発生しなくなったようなので良い感じだ。Miharaさんの協力に感謝。

Bug 4814 ダウンロード終了時に表示されるアラートの動作が重い 初回投稿日時: 2005年11月27日08時35分22秒
カテゴリ: Firefox Thunderbird
固定リンク: id=2005112701
リンク元: 1件
SNS: (list)

アラートのウインドウがにょきっと出てくる時にCPUパワーをすごく使っているというバグ。本家を探しても同様のバグが見つからなかった。とりあえず、wontfixとした。

ソースコードを見てみると、アニメーションの設定を細かく指定できるようになっているので、アニメーションが重い場合は次の設定を変更してみて欲しい。

alerts.slideIncrement

一フレームで何ピクセル、ウインドウを大きくするか。初期値は1(ピクセル)。

alerts.slideIncrementTime

一フレームを何ミリ秒とするか。初期値は10(ミリ秒)。

フレーム数を半減させて、一フレームで元と同じだけウインドウを大きくすれば、アニメーションのなめらかさと引き替えにパフォーマンスを向上させることができる。例えば、alerts.slideIncrementを2、alerts.slideIncrementTimeを20とすると、20ミリ秒に一回、2ピクセルずつウインドウが大きくなるので、コストを半減できる。