この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
ゴールデンウイーク明けから引っ越し準備予定です。というわけでゴールデンウイーク以降はあまり反応が良くない可能性があります。ゴールデンウイーク中は無休の予定なので何かありましたら今の内にどうぞ。
ちょっと軽い
のあたりが気になった。デスクトップ版のOperaがFirefoxに比べて極端に省メモリなんてことは無いと思う。使い方に依存する話だが、Bug-org 131456のテストは結構現実的というか、一般的な用途を自動化したものだと思うので、テスト結果は信頼できると思う。(Operaもメモリ食いだと言いたいのではなく、このへんの数値が妥当な線なのだと思う。)
というか、数値化可能な比較はちゃんとテストして欲しいと思う。50個ものタブを開いた時の話なんて私にはただのストレステストにしか思えないのだが、主張する以上はその条件も明記して欲しい。例えば、50個のサイトを開いた状態なのだろうか? それとも1個のサイトを50回開いた状態なのだろうか? 後者は共通の画像等をタブ間でシェアする等で省メモリ化可能だが、それは現実の用途で有効な処理だとは思わない。また、テスト環境のメモリ容量や具体的にどの程度のメモリ消費量の差があったのか等が気になる。
IRCなんかでも、言いたいことがどうもよく伝わっていないようなので補足。
だが、省メモリ環境下でさくさく動くのはOperaだと感じている。具体例を挙げるのは簡単だ。手元のFirefoxで50個位のタブを開いてみればすぐに分かる。余程メモリに余裕がある環境でない限り使う気にならない速度になってしまうだろう。Operaは50個程度のタブではびくともしない。
と書かれていたことに対するのが、私の上記の反応。
要するに、メモリ消費量が増えたことによる処理落ちの話、ということから私はディスクスワップが発生したことによる処理落ちだと判断した。(他に思いつかない。)
で、このようにFxとOperaで大きな差が出るのであれば、そこにはメモリ使用量にかなりの差がないと、公平なテストではその差はでないはずである。だが、以前私がテストした結果から、FxもOperaも大してメモリ消費量に差がないという経験と知識がある。
このことをふまえて、引用した文章を読んでみて欲しい。
ようやくborder描画コードのリファクタリング第一弾が入った。
TrunkのGeckoではこのサイトのスタイルシートは完全に表示できるようになってしまった。また、ブラウザいじめな感じのスタイルシートを作らないとテストにならないな。
なんて私が言っちゃまずいんですが。
でも、1.8branchが切られてからすでに1年半を軽く超えてますね(CVSのログから察するに2005年8月?)。私がtrunkでのみ修正したバグも既に80件オーバー。どうりで記憶だけではどのバグがtrunkでのみ修正されたのかさっぱり覚えてない訳だ。
jshinにつっこまれるまでど忘れしていたバグ。
エディタ以外ではIMEを無効にしてしまうことで、メニューへのアクセスを確保していただけなので、エディタはこのバグを抱えたままだった。
当初はOSの挙動を忠実に再現しようかと思い、苦労したが、どうにも問題がある感じなので、一律、メニューが開いて、キーボードの処理をメニューがフックした時点で未確定文字列を確定して無効にしてしまうように修正した。
パッチの作成からチェックインまで約4ヶ月。最後の最後まで手こずったが修正完了。これでLinuxのテキストレンダリングも有る程度まともなものになったはず。
ようやく実装完了。Geckoにおけるime-modeの仕様は以下の通り。
| 値: | auto | normal | disabled | active | inactive | inherit |
| 初期値: | auto |
| 適用対象: | テキストを編集可能な要素 |
| 継承: | しない |
| パーセント値: | N/A |
| メディア: | interactive |
| 算出値: | 指定値 |
IEとの違いを説明を列挙すると、
IEではパスワードエディタには適用されないが、Geckoでは適用可能。
IMEの状態を通常の状態、つまり全ての機能が使える状態にする。この値を利用すれば、ime-mode: disabled;の指定されたエディタであってもユーザスタイルシートで強制的にIMEを利用可能とすることができる。
また、パスワードエディタであってもこれを利用することでIMEを利用可能とする。
MacではIMEの無効状態とパスワード入力欄での状態とは異なる。Macでの不整合を防止するために、disabled値はパスワード入力欄の標準的な挙動に割り当てられる。
つまり、Macでは非Romanのキーボードレイアウトが選択できなくなる。WindowsやLinuxではこれらの区別はないため、IMEのみが単純に無効化されると考えて問題無い。
MSDNのドキュメントによると継承するとなっているが、IE6/IE7で挙動を確認したところ、継承しない。GeckoはIEの挙動にあわせて実装している。
他にもいくつか注意点。
まず、Linuxではactive、inactive値はnormal値と同じ挙動となる。これはプラットフォームの持つAPIの制限によるもの。
Macではime-mode: disabled;のエディタがフォーカスを取得するとキーボードレイアウトがRomanのものに切り替えられるが、このエディタがフォーカスを失う際に元の状態への復元は行われない。これはCocoaのパスワードエディタの標準的な挙動であるが、他のプラットフォームの挙動とは異なっている。つまり、ime-mode: disabled;の使用はMacユーザには非常に嫌われることが予想される。
もちろん、このプロパティを一般的なWebページで使うことは推奨されない。このプロパティはイントラネットのアプリケーション等、ユーザがそのフォームの仕様を熟知している場合を除き、使用されるべきではない。ユーザは一般的にIMEの状態(ON/OFF)を記憶しており、その状態を逐次確認しながら利用することはないと思われる。そのため、ユーザの記憶と実際の状態に齟齬が発生する可能性のあるactiveとinactiveの利用は慎重に行われるべきである。
また、メールアドレスの入力欄等、ASCII文字しか使えないエディタでのIMEの無効化も推奨されない。ユーザによってはメールアドレス等をIMEの辞書に保存し、利用している可能性があるためである。このような利用方法をとっているユーザにとっては「余計なおせっかい」でしかない。
Webページの作者はこのプロパティをフィルタに使えるものと考えてはいけない。Geckoは貼り付け(ペースト)を利用することで、IMEを利用しなくてはいけない文字であってもIMEが無効なエディタに入力可能である。
絶賛意見募集中。
というか、このへん、CSS仕様の定義が適当すぎ。レンダリングのためのレイアウトはactual valuesのみが利用されるべきだと思うんだけどなぁ。(それが真なら、このバグはバグではなくなる。)
position: fixed;なボックスがあるとスクロール時にちらつきが発生していたバグが今夜のビルドから修正されている。