Latest topics 近況報告

MozStorageを使う時にメモリリークを防いだりオーバーヘッドを減らしたり - Jan 09, 2009

mozIStorageStatement.finalize() メモ - 1/4ガロン

うっ。僕の知識は古かった。Firefox 3 Hacksで、createStatement()で作ったステートメントは使い終わったらstatement.reset()、と書いてましたが、statement.finalize()が正解だったようです。

が、一律にこう置き換えるとよい、というわけでもないのがややこしい所です。mozIStorageStatementのfinalizeメソッドはどうやらFirefox 3.0.x（Gecko 1.9）で導入された物のようで、Gecko 1.8系では存在しません。なのでメソッドを呼ぶ前に存在確認をしておかないといけない。Firefox 2なんてもうサポート終了してんじゃん！と思うかもですが、Thunderbirdはまだ2.0.0.xが現役なのでもうしばらくは気をつけないといけないんですハイ。

ところで、僕はずっと誤解してしまってたんですが、ステートメントはstatement.reset()でリセットすると、バインドするパラメータを変えて何度も使い回せるんですね。createStatement()のオーバーヘッドがどのくらいなのかよく分からないのでアレなんですが、SQL文が変わらない時はキャッシュしたステートメントを使い回すようにするという形で、高速化を図れるでしょうか。XUL/Migemoに早速活かしてみたいと思います。

Firefox 3.1のスマートロケーションバーまわりがわけわからん！ - Jan 09, 2009

• 「Location bar search (1)」 - Scene Side B
• Firefox 3.1: スマートロケーションバーの絞込み - えむもじら
• Firefox 3.1の主な変更点を日本語で - Mozilla Flux

現時点までで、以下の設定項目が新設されたところまでは把握してる。

• browser.urlbar.restrict.history（文字列型）
• browser.urlbar.restrict.bookmark（文字列型）
• browser.urlbar.restrict.tag（文字列型）
• browser.urlbar.restrict.typed（文字列型）
• browser.urlbar.match.title（文字列型）
• browser.urlbar.match.url（文字列型）
• browser.urlbar.default.behavior（整数型）：Bug 463459 – Use a separate pref instead of empty restrict/match values to specify defaults により追加された。restrictとmatchの値が「空の場合は」云々の特例的な処理を一本化するための物。
• browser.urlbar.search.sources（整数型）

以下は削除された、と。

• browser.urlbar.matchOnlyTyped（真偽型）

が、どれがどんな風に働くのかがごちゃごちゃして分からんようになってきた……

browser.urlbar.default.behavior（フラグを指定しておくことで、restrictとかmatchとかの指定をしたのと同じ状態から検索をスタートする）に3を指定するのと、browser.urlbar.search.sourcesに3を指定するのとの、違いがいまいち分からない。ので、ソースをあちこち辿ってみた。見てみた感じでは、どうやらnsNavHistoryのProcessTokensForSpecialSearchメソッドが鍵になってるっぽい。

検索対象のテーブルの指定や絞り込みの条件は、すべてmAutoCompleteCurrentBehaviorという1つの変数にフラグとして格納される。

• 1（最下位ビットがON）は、履歴だけを検索対象にする。
• 2（下から2番目のビットがON）は、ブックマークだけを検索対象にする。
• 4（下から3番目のビットがON）は、タグ付けされている項目だけを検索対象にする。
• 8（下から4番目のビットがON）は、タイトルにマッチする。
• 16（下から5番目のビットがON）は、URIにマッチする。
• 32（下から6番目のビットがON）は、ユーザがロケーションバーから手動操作で訪問した項目だけを検索対象にする。

これらを踏まえて、以下の順で処理されている。

1. browser.urlbar.default.behaviorの指定でmAutoCompleteCurrentBehaviorを初期化する。
2. browser.urlbar.search.sourcesを見て、
   1. 1だったらmAutoCompleteCurrentBehaviorの最下位ビットをONにする。
   2. 2だったら下から2番目のビットをONにする。
   3. それ以外の時（0や3）は何もしない。（browser.urlbar.search.sourcesが0の時、つまりスマートロケーションバーの検索機能自体を無効にしている時は、ここにそもそも処理が回ってこない？）
3. スマートロケーションバーに入力中の文字列をトークンごとに分割して、restrictやmatchで設定されている文字列と比較する。一致したらその都度、mAutoCompleteCurrentBehaviorの対応するビットをONにしていく。
4. 入力中の文字列が空の時は、最下位ビットと下から6番目のビットをONにする。（Bug 426864 – Only show user typed history pages for the urlbar dropdown によって追加された処理で、ユーザが何も入力してない状態でドロップダウンリストを開いたら過去の入力履歴だけを表示する、という挙動をこれによって再現する。）
5. ここまでの結果のmAutoCompleteCurrentBehaviorを見て、以下の順で、どのSQL文を使うかを決定する。これは排他的な選択なので、どれかの道に分岐したらその時点で検索条件が確定する。
   1. 下から3番目のビットがONの場合、タグ付けされた項目だけを検索するSQL文を使う。
   2. 下から2番目のビットがONの場合、ブックマークだけを検索するSQL文を使う。
   3. 下から6番目のビットがONの場合、ユーザがロケーションバーから手動で訪問した項目だけを検索するSQL文を使う。
   4. 最下位ビットがONの場合、履歴だけを検索するSQL文を使う。
   5. 上記ビットがいずれもOFFの場合、履歴とブックマークの両方を対象に検索するSQL文を使う。
6. 下から4番目のビットと下から5番目のビットは、次の段階での絞り込みに使われる。

ああややこしい……

• 5のステップでは排他的な選択になっているので、例えば「タグ付けされた項目で、且つ、ロケーションバーから訪問した事がある物だけを対象に検索する」という風なことはできないようだ。
• 条件を指定する方法には、browser.urlbar.search.sources、browser.urlbar.default.behavior、検索時のキーワード入力の3つがあるが、これら3つの間には優先順位は無い。優先順位は各ビットの方にあって、常に5-1から5-5の順番に従って判定される。なので、以下のような不可解なことが起こる。
  • browser.urlbar.default.behaviorを使って、ブックマークからのみ検索を行うようにした状態（下から2番目のビットがON）で、検索時語句の中に「^」を含めて履歴のみの検索を指示した（最下位ビットがON）、という場合、手動で指示した検索条件はまるっきり無視されて、あくまでブックマークからのみ検索が行われる。
  • browser.urlbar.default.behaviorを使って、ユーザがロケーションバーから手動で訪問した項目だけを検索対象にするように指定（下から6番目のビットがON）していても、検索時語句の中に「+」が含まれていた（下から3番目のビットがON）場合には、手動で指定した方の条件が優先されて、タグ付けされた項目からのみ検索が行われる。
• browser.urlbar.default.behavior=3とbrowser.urlbar.search.sources=3の違いは、前者は「ブックマークされていて且つ履歴にも含まれている（＝訪問済みのブックマーク）」項目だけが検索対象になり、後者は「ブックマークと履歴の全体」が検索対象になる、という点。search.sourcesが0（検索機能自体が無効になっている）以外で、default.behaviorが3の時は、両方の条件がMIXされて、browser.urlbar.default.behavior=3の条件と同じ（ブックマークと履歴の全体から訪問済みのブックマークだけを検索するのも、ブックマークから訪問済みのブックマークだけを検索するのも、履歴から訪問済みのブックマークだけを検索するのも、全部同じ事ですね）になる。

その場での入力とデフォルト設定のどっちが優先されるのか、がパッと分からないのってどうかと思うんだけど……XUL/Migemoのスマートロケーションバー周りの挙動をこれに合わせないといけないんだけど、こういうわかりにくい挙動をそのまま再現するというのは、モチベーションが上がらないなあ。（ていうかバグ立ってそう）

21日追記。browser.urlbar.search.sourcesが廃止されてこのエントリの内容のかなりの部分は無駄になりました。

MozillaがWindows Mobile上で動いてる様子のデモ - Jan 08, 2009

弊社の足永さんが、Windows Mobile（エミュレータ）上でMozillaが動作している様子のデモ動画を公開してくださいました。YouTubeを見てみた所、Windows XP上で動くFennecの動画はいくつかあるみたいですが、Windows Mobile上での物の動画となるとこれが一番乗りっぽい？

Mozilla Add-onsのメリットデメリット - Dec 16, 2008

アドオン作者にとって、Mozilla Add-onsにアドオンを登録することには以下のようなメリットがある。

• アドオンの配布ページを簡単に国際化できる（翻訳は誰かがしないといけないけど、ページの方はシステムで用意してくれて、ユーザの言語に合わせて適切な物が自動選択される）。
• 統計情報を利用できる（日々のダウンロード数、アクティブユーザ数など）。
• セキュアな方法で公開できる。ユーザは、第三者によって改竄されていないことを保証された状態で安心してアドオンをインストールできる。
• 過去のバージョンの更新履歴とインストールパッケージを自動で残してくれる。ユーザが「古いバージョンに戻したい」と思った時にいつでも好きなバージョンを入れられる。
• レビューを付けたりランキングを付けたりといった機能。
• アドオンのポータル、ということになっているので、利用者増が見込める（利用者は基本的に世界規模）。

ただし、場合によっては「べつにAMOじゃなくてもいいじゃん」と言える事もある。例えば日本語圏のユーザに特化したアドオン、はてなのサービス専用のアドオンなどであれば、AMOにおける国際化や「グローバルを相手にアピールできるぜ」関係の機能のメリットはあまり意味がない。統計情報やセキュアな公開方法・更新方法（＝SSL）、過去のバージョンの保存などを自前でできていて、ランキングやレビューも特にいらないということだったら、AMOに登録するメリットはほとんど無いということにもなるだろう。

それどころか、逆に、一般公開されるまでに審査待ちのタイムラグが生じるとか、そもそも一般公開されるために必要なレビューが集まらなかったりエディタの人に公開を承認してもらえなかったりすらする（今アクティブに活動してる人で日本語圏の人はいない状態だと以前聞いた）、そんな感じでデメリットの方が大きくなってしまうとも言える。

要は適材適所ということですね。

スクロールバーのクリックでスクロールしなくなる現象 - Dec 15, 2008

普段、ページをスクロールするのにスクロールバー上のクリックだとかホイールの回転だとかキーボードのPageUp/PageDownキーだとかスペースキーだとか色々使ってるんだけど、ここ数日、なんかスクロールバーの空白部分でのクリックだけ突っかかるっていうか詰まるっていうか急にスクロールしなくなる現象が自分の手元では起こっている。下方向にスクロールしてる時に、急に、クリックしても何も起こらなくなる。ホイールスクロールしたり、一度上方向にスクロールしたりすると、「詰まり」が解消されてまた下方向にスクロールできるようになる。

「click scrollbar」とかで検索しても他に同じ問題を報告してる人がいないような感じだったし、いまいち確実な再現条件が特定できない――他の環境でもこうすれば確実に発生しますよ！と断言できそうな条件が分からない、自分の手元の環境でも起こったり起こらなかったりしてるので、WORKSFORMEとかINVALIDとかにされてまた永久に放置食らいそうな気もするけど、問題が起こるようになってから数日経ってもなお現象が発生し続けているので、直れば儲け物だと思ってダメ元で一応登録してみた。

Bug 469613 - Clickings on scrollbar's blank areas (above or below the thumb) don't scroll the page, if the page is very long.

問題があるとしたらきっとC++の層での話だと思うので、条件が特定できたとしても僕には絶対にパッチ書けません。パッチ書ける人誰かフォローしてください。それか、僕には既にある同様のバグを見つけられませんでしたが、もしあるならDUPLICATEDにして下さい。

ってこんなネットの辺境で書いても誰も見てないんでしょうけどね。

追記。他の人の環境でも再現されて、どうやら原因になった改変が行われたバグなどが特定されたようです。中野さんのフォローのおかげです。ありがとうございます。

MDCの自動テスト関係のドキュメントの翻訳 - Dec 12, 2008

UxUにFirefox用のテストケースを実行する機能を加えるにはそもそもFirefox用のテストケースの仕様を調べないといけない、ということでそこら辺の文書をあたってみたら全然翻訳されてなかったので、次にパッチを書く時（あるのか？）のための勉強も兼ねて翻訳しまくってる。

• Mozillaの自動テスト
• Chromeテスト
• Browser chromeテスト
• Mochitest
• xpcshell

アサーション用の関数の引数の順番の理解を間違えていた……というか元の英語の文書で「thingAとthingBを比較」とか酷い書かれ方になってたので、SimpleTestのソースを確認して、「actualValueとexpectedValueを比較」という風に読んだら意味が分かるようにしておいた。こういう事があると、確かに須藤さんの言う「駄目なことはできないような設計」というのは重要なのだなあと改めて思う。

「テストハーネス（test harness）」って一般的な用語なんだろうか。よく分かんなかったから全部「テスト実行環境」って訳した。問題あるようだったら誰かが勝手に直してくれることに期待してる。→やっぱりテストハーネスで統一した。一応訳註も入れてるけど。

Shiretokoのロボをリ～ファ～イ～ン～（完成版） - Dec 11, 2008

Firefox 3.1 beta2のスタートページのロボをカトキ立ちさせてみたものに色を塗りました。 これで一応完成としとこう。

以下、設定。

• FXドライブ（<ruby><rb>地球</rb><rp>（</rp><rt>ちたま</rt><rp>）</rp></ruby>炉）搭載。 / He has the "FX Drive", aka "telluric reactor".
  • FXドライブは地球からエネルギーを取り出す半永久機関で、世界に一つしかないオーバーテクノロジー。 / "FX Drive" is a semi-perpetual generator. The energy is from the Earth. It is built on over-technologies, and there is no other FX Drive.
  • FX粒子で無敵。 / He is invincible because of "FX Particles" from the FX Drive.
• キャッチコピーは「ブラウザ戦争に武力介入を開始する」。
• アドオンでパワーアップできる。左手の武器もアドオン。 / He can be extended by addons. The drill of his left hand is also an addon.
• 本気出すとサイコフレームが光ってフェイスオープンしつつFXドライブにアレのマークが浮かび上がるぞ。 / In an emergency, his psycho-frame glows, the mask becomes open (the "face-open" mode), and the mark of the red fox appears in the FX Drive.

アレとかソレとかが微妙にどころか盛大に混ざってますね。

ていうか色塗る前にGenさんのブログに捕捉されてしまって、慌てて完成させた。planet.mozilla.orgから来た人とか、カラー版に辿り着けるんだろうか？　せめてもの……（？）ということで英語圏の人のために↑のネタを一部訳してみた。文化と言語の壁を越えてワロタしてもらえれば幸いだ。

ところで本家のイラストを描いたのはJosh Burcham氏という方だそうで、deviantARTにある絵を見ると、Shiretokoのアレは分かりやすいかっこよさをわざと外したところを狙って描いたんだろうということがよく分かる。モテる人のための音楽が苦手な僕が、聴くことをついためらう曲は…にもモテる人たちは「ベタすぎるのはかっこ悪い」と思ってるから、音楽の好みも、ベタベタなポップソングより「クールなBGM」っぽい音楽を好むとあるように、元絵の方が世の中的にはずっとクールで格好良くて、僕の描いてるようなのはベタベタすぎてカッコ悪い訳です。

追記。うは、Mozilla Linksに載っちゃったよ。

Firefoxのテスト環境が…… - Dec 10, 2008

Browser chrome tests - MDC 見ながらなんとか環境整えてビルドしてテスト実行して……という風な事をしてみたけど、テスト結果のあまりのわかりにくさに閉口した。しかも一個テストがこけたら後の物も続けて失敗するし。クリーンなプロファイルで起動してくれるのはいいけど、あとがもうメタメタすぎて、とても常用（？）する気にならないよ……

というわけでUxUの次のテーマはFirefoxのソースツリー上にある自動テストを実行する機能ということにしたいと思います。

• イベント関係のユーティリティのエイリアスを作る。
• waitForExplicitFinish()とfinish()での非同期テストをサポートする。
• 実行コンテキストを新しく開いたブラウザウィンドウに固定する（テストごとにウィンドウを破棄）。

この辺が鍵でしょうか。

追記。概要をつかむために説明を翻訳した。これによると、「browser_*.js」という名前のファイルだけがブラウザ用のテストとして認識されるようなので、ファイル名がこのルールに一致していたら上記のような特別な処理を行うようにする、という感じで行けそう。

Shiretokoのロボをリ～ファ～イ～ン～ - Dec 09, 2008

beta1、beta2と描かれているアレを勝手にリファインしてみてるYO！ 口元や胸の光ってるのをサイコフレームの燐光と勝手に解釈して激しくユニコーンガンダムくさいディティールに。腹の円は……まあ、GNドライブくさいけど位置も形もコレ以外にないよねえってことで。

こんな時に何をやってるんだろう自分は。

追記。全身できた。 線画だけど。

左手が元絵だと剣？っぽいのが何故かドリルになってるのは、日本の燃える男の武器といえばドリルだからです。ドリル。

バストアップ。 顔はこんな感じ。赤いアンテナをどうしようか悩んだけど、なるべくシルエットは残す方向で。

カトキ立ちに黄金比テンプレは欠かせません。

さらに追記。細かい手直しついでに、少しディティールを変えた。

さらに追記。色塗りました。

XUL/Migemoで、非表示の要素の中にマッチする文字列があったときに検索結果がおかしくなる問題で悩んでる - Dec 05, 2008

掲示板の方で障害報告を受けていた、正規表現にマッチするはずなのに強調表示される物とされない物があるという問題。原因を色々調べてみたら、非表示の要素が問題を引き起こしていた。

<fieldset>
<legend style="display:none">b</legend>
<p>a b a c</p>
</fieldset>

例えばこんな箇所を検索対象にして、a|bという正規表現で検索するとする。

XUL/Migemoはまず一旦検索対象の範囲をDOM Rangeで取得して、文字列に変換し、それに対して正規表現のマッチングを行う。この場合、Rangeからは「b a b a c」という風な文字列が得られ、最初にマッチした「b」がヒット箇所ということになる。

次に、この「実際にヒットした文字列」を使ってFirefox自身の持つ検索機能を呼ぶんだけど、ここで問題が起こる。Rangeの文字列化では要素が表示されてるかどうかというのは考慮されないんだけど、nsIFindのRange内検索では、ヒット箇所が非表示の要素の中だった場合はヒットしなかったものとして次候補を探してしまう。上記の例では、非表示のlegend要素の中に「b」という文字列を見つけても、非表示だからということでスルーされてしまい、実際には次のp要素内の「b」という文字列の方にヒットしてしまう。

XUL/Migemoで次候補を検索すると、次の（2つ目の）「a」にはヒットする。さらに次候補を検索すると、文書の終了に達して文書先頭から検索し直されるのだけれども、この時も上記のような事が起こって、p要素内の1つ目の「a」ではなくp要素内の「b」がヒットする。よって、普通の前方検索を行っている間は永久に、p要素内の1つ目の「a」にはマッチしないという現象が起こる。

Rangeを文字列化する時に、非表示の要素を除外できればいいんだけど……

ちなみに現在のところ、Rangeを文字列化する時は、DOM3 XPathを使ってscript要素などを検出してそこを避けるように文字列化してるんだけど、要素の表示・非表示をキーにしようとするとDOM2 TraversalのTreeWalkerを使わないといけないと思う。TreeWalkerではすべての要素ノードに対してJavaScriptの関数呼び出しと条件判定が行われるので、長いページだとヤバイくらいに速度低下が起こりそう……という懸念があって、手を出せずにいる。

追記。実際にそのように実装して試してみたところ、確かに正しく検索できるようにはなるんだけど、Rangeを文字列化する処理自体が10倍遅くなった。これはまずいなあ。