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

もずはっく日記(2007年5月)

2007年5月1日

引っ越し準備 初回投稿日時: 2007年05月01日00時25分23秒
カテゴリ: 雑談
固定リンク: id=2007050100
リンク元: 0件
SNS: (list)

ゴールデンウイーク明けから引っ越し準備予定です。というわけでゴールデンウイーク以降はあまり反応が良くない可能性があります。ゴールデンウイーク中は無休の予定なので何かありましたら今の内にどうぞ。

Re: Operaの良いところ 初回投稿日時: 2007年05月01日16時21分35秒
最終更新日時: 2007年05月02日01時38分16秒
カテゴリ: Firefox Opera 雑談
固定リンク: id=2007050101
リンク元: 6件
SNS: (list)

ちょっと軽いのあたりが気になった。デスクトップ版のOperaがFirefoxに比べて極端に省メモリなんてことは無いと思う。使い方に依存する話だが、Bug-org 131456のテストは結構現実的というか、一般的な用途を自動化したものだと思うので、テスト結果は信頼できると思う。(Operaもメモリ食いだと言いたいのではなく、このへんの数値が妥当な線なのだと思う。)

というか、数値化可能な比較はちゃんとテストして欲しいと思う。50個ものタブを開いた時の話なんて私にはただのストレステストにしか思えないのだが、主張する以上はその条件も明記して欲しい。例えば、50個のサイトを開いた状態なのだろうか? それとも1個のサイトを50回開いた状態なのだろうか? 後者は共通の画像等をタブ間でシェアする等で省メモリ化可能だが、それは現実の用途で有効な処理だとは思わない。また、テスト環境のメモリ容量や具体的にどの程度のメモリ消費量の差があったのか等が気になる。

IRCなんかでも、言いたいことがどうもよく伝わっていないようなので補足。

だが、省メモリ環境下でさくさく動くのはOperaだと感じている。具体例を挙げるのは簡単だ。手元のFirefoxで50個位のタブを開いてみればすぐに分かる。余程メモリに余裕がある環境でない限り使う気にならない速度になってしまうだろう。Operaは50個程度のタブではびくともしない。

と書かれていたことに対するのが、私の上記の反応。

要するに、メモリ消費量が増えたことによる処理落ちの話、ということから私はディスクスワップが発生したことによる処理落ちだと判断した。(他に思いつかない。)

で、このようにFxとOperaで大きな差が出るのであれば、そこにはメモリ使用量にかなりの差がないと、公平なテストではその差はでないはずである。だが、以前私がテストした結果から、FxもOperaも大してメモリ消費量に差がないという経験と知識がある。

このことをふまえて、引用した文章を読んでみて欲しい。

2007年5月2日

Bug-org 368247 Rewrite border rendering for Thebes 初回投稿日時: 2007年05月02日01時57分08秒
カテゴリ: Mozilla Core
固定リンク: id=2007050200
リンク元: 0件
SNS: (list)

ようやくborder描画コードのリファクタリング第一弾が入った。

  • radiusの処理がかなり綺麗になっている。
  • border、outline共に位置、太さは物理ピクセルに丸められるため、AAによるにじみは無い。
  • dottedの点が四角から丸に変更された。当然、丸はAAで滑らか。
  • dottedのborderの結合はまだ変。

スタイルシート、また作り替えないと 初回投稿日時: 2007年05月02日02時10分37秒
カテゴリ: WebStudio
固定リンク: id=2007050201
リンク元: 0件
SNS: (list)

TrunkのGeckoではこのサイトのスタイルシートは完全に表示できるようになってしまった。また、ブラウザいじめな感じのスタイルシートを作らないとテストにならないな。

リリースビルドなんてもう分かんない 初回投稿日時: 2007年05月02日02時43分52秒
カテゴリ: Firefox Thunderbird
固定リンク: id=2007050202
リンク元: 0件
SNS: (list)

なんて私が言っちゃまずいんですが。

でも、1.8branchが切られてからすでに1年半を軽く超えてますね(CVSのログから察するに2005年8月?)。私がtrunkでのみ修正したバグも既に80件オーバー。どうりで記憶だけではどのバグがtrunkでのみ修正されたのかさっぱり覚えてない訳だ。

2007年5月6日

Bug 5684 [Win][GTK2] エディタ上でIMEがオンだとメニューのニーモニックが使えない 初回投稿日時: 2007年05月06日04時13分42秒
カテゴリ: Mozilla Core
固定リンク: id=2007050600
リンク元: 0件
SNS: (list)

jshinにつっこまれるまでど忘れしていたバグ。

エディタ以外ではIMEを無効にしてしまうことで、メニューへのアクセスを確保していただけなので、エディタはこのバグを抱えたままだった。

当初はOSの挙動を忠実に再現しようかと思い、苦労したが、どうにも問題がある感じなので、一律、メニューが開いて、キーボードの処理をメニューがフックした時点で未確定文字列を確定して無効にしてしまうように修正した。

2007年5月9日

Bug 5553 [Cairo][pango] PangoFontの取得に時間がかかることがあるので、PangoFontはキャッシュするべき 初回投稿日時: 2007年05月09日01時35分09秒
カテゴリ: Mozilla Core
固定リンク: id=2007050900
リンク元: 0件
SNS: (list)

パッチの作成からチェックインまで約4ヶ月。最後の最後まで手こずったが修正完了。これでLinuxのテキストレンダリングも有る程度まともなものになったはず。

2007年5月23日

Bug 4223 ime-modeプロパティの実装 初回投稿日時: 2007年05月23日17時58分06秒
最終更新日時: 2007年07月22日14時35分09秒
カテゴリ: CSS Mozilla Core
固定リンク: id=2007052300
リンク元: 16件
SNS: (list)

ようやく実装完了。Geckoにおけるime-modeの仕様は以下の通り。

'ime-mode'
値:  auto | normal | disabled | active | inactive | inherit
初期値:  auto
適用対象:  テキストを編集可能な要素
継承:  しない
パーセント値:  N/A
メディア:  interactive
算出値:  指定値

IEとの違いを説明を列挙すると、

input[type=password]にも適用可能

IEではパスワードエディタには適用されないが、Geckoでは適用可能。

normal値の追加

IMEの状態を通常の状態、つまり全ての機能が使える状態にする。この値を利用すれば、ime-mode: disabled;の指定されたエディタであってもユーザスタイルシートで強制的にIMEを利用可能とすることができる。

また、パスワードエディタであってもこれを利用することでIMEを利用可能とする。

disabled値はIMEの無効化ではなく、パスワードエディタと同様の挙動とする

MacではIMEの無効状態とパスワード入力欄での状態とは異なる。Macでの不整合を防止するために、disabled値はパスワード入力欄の標準的な挙動に割り当てられる。

つまり、Macでは非Romanのキーボードレイアウトが選択できなくなる。WindowsやLinuxではこれらの区別はないため、IMEのみが単純に無効化されると考えて問題無い。

継承しない

MSDNのドキュメントによると継承するとなっているが、IE6/IE7で挙動を確認したところ、継承しない。GeckoはIEの挙動にあわせて実装している。

他にもいくつか注意点。

まず、Linuxではactiveinactive値はnormal値と同じ挙動となる。これはプラットフォームの持つAPIの制限によるもの。

Macではime-mode: disabled;のエディタがフォーカスを取得するとキーボードレイアウトがRomanのものに切り替えられるが、このエディタがフォーカスを失う際に元の状態への復元は行われない。これはCocoaのパスワードエディタの標準的な挙動であるが、他のプラットフォームの挙動とは異なっている。つまり、ime-mode: disabled;の使用はMacユーザには非常に嫌われることが予想される。

もちろん、このプロパティを一般的なWebページで使うことは推奨されない。このプロパティはイントラネットのアプリケーション等、ユーザがそのフォームの仕様を熟知している場合を除き、使用されるべきではない。ユーザは一般的にIMEの状態(ON/OFF)を記憶しており、その状態を逐次確認しながら利用することはないと思われる。そのため、ユーザの記憶と実際の状態に齟齬が発生する可能性のあるactiveinactive利用は慎重に行われるべきである。

また、メールアドレスの入力欄等、ASCII文字しか使えないエディタでのIMEの無効化も推奨されない。ユーザによってはメールアドレス等をIMEの辞書に保存し、利用している可能性があるためである。このような利用方法をとっているユーザにとっては「余計なおせっかい」でしかない。

Webページの作者はこのプロパティをフィルタに使えるものと考えてはいけない。Geckoは貼り付け(ペースト)を利用することで、IMEを利用しなくてはいけない文字であってもIMEが無効なエディタに入力可能である。

2007年5月26日

Bug-org 381920 physical units rounding error 初回投稿日時: 2007年05月26日00時12分12秒
カテゴリ: CSS Mozilla Core
固定リンク: id=2007052600
リンク元: 1件
SNS: (list)

絶賛意見募集中。

というか、このへん、CSS仕様の定義が適当すぎ。レンダリングのためのレイアウトはactual valuesのみが利用されるべきだと思うんだけどなぁ。(それが真なら、このバグはバグではなくなる。)

2007年5月29日

Bug-org 324819 Fixed positioned elements now lag/flicker when scrolling (regression from bug 317375) 初回投稿日時: 2007年05月29日03時16分11秒
カテゴリ: Mozilla Core
固定リンク: id=2007052900
リンク元: 0件
SNS: (list)

position: fixed;なボックスがあるとスクロール時にちらつきが発生していたバグが今夜のビルドから修正されている。

Twitter

Masayuki Nakano(問い合わせ先)