Latest topics 近況報告

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 Add-onsのメリットデメリット - Dec 16, 2008

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

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

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

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

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

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

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

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

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

この辺が鍵でしょうか。

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

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倍遅くなった。これはまずいなあ。

危険なアドオン、悪意あるアドオン、低品質なアドオン - Dec 05, 2008

FirefoxでAmazonの商品ページを見た時に違法ダウンロードのリンクを自動挿入するという、倫理的に宜しくないアドオンの話のコメントでタブブラウザ拡張の話が引き合いに出されていたので久しぶりに読み返してみた。

ああ、懐かしいなあ。こんな時もあったなあ。

この時はTBEが叩かれてTabMixが祭り上げられてたけど、今となってはTabMixPlusがこの時のTBEと同じような叩かれ方をしてる（TMPがアップデートされるまでFirefox 2から3に移行できない、とか、ロックインのような状態も発生してる）というのは、性格の悪い僕としては「ざまみろプギャー」と思わずにはいられません。

あの頃と状況が変わった点と言えば、当時はリリース版よりナイトリービルドの方を使うようなマニアな人の方が多かったから毎日のようにTBEが本体の変更の影響を受けてマトモに動かなくなって大問題になってたけど、今ではリリース版を使う人の方が多くてその手の「昨日は動いたのに今日はもう駄目になってる」という事態が発生することが減ったことと、あと、わりかしザル気味とはいえAMOのチェック機構のおかげで、入れた瞬間に必ずクラッシュするようなひどいアドオンにぶち当たることが少なくなったこと、あたりがあるでしょうか。他にも、Mozilla自体の作りがだいぶマシになって余計な危険なことをしなくてもよくなったとか、MDC等でドキュメントが充実してきて平均的な技術レベルが向上したとか、そういうのもあるのかも。

僕個人についても、自動テストを導入し始めたとか、他のアドオンとなるべく衝突しなくてすむようなやり方を色々考えるようになったとか、色々変わったとは思う。

しかしこういう（悪意有るアドオン云々の）話題だったらむしろ、以前にプレゼンしたCドライブを強制的にフォーマットするようなヤバイ拡張機能の話の方が適してるような気もするんだけど。でもこの時のはプレゼン資料しか公開してないんだよなあ。これだけ見ても意味分からんか。

リンクから開かれた新しいタブでも「戻る」を使えるようにするTab Historyがイイ - Dec 03, 2008

Firefoxタブ常用者のための最新エクステンションガイド - SourceForge.JP Magazine で「ツリー型タブを入れてるとTab History が無効になる」と書かれてたので「なに！」と思って入れてみたんだけど今の所特に不具合無く動いてるように見える。一応ソースも見てみたけど、特に衝突する点も無いような……一カ所「もしかして、ここか？」と思う所は無くもないんだけど。そこだけ次版で手を入れておくか……（追記：ツリー型タブ 0.7.2008120401で一応手を入れてみた）

その問題はさておき、Tab Historyは確かに良い。万人にお勧めできると思う。よくある「初心者ユーザがリンクをクリックした時に勝手に新しいウィンドウが開かれて、それが全画面表示になっているせいで、『元のページに戻りたいのに戻るボタンを押しても何も起こらないムキー！！！』となってしまう」という現象、のタブ版を防ぐ物だと言えるだろう。自分はよく、あるタブから子タブを開く→子タブを見ている間に親タブを閉じる→やっぱり親タブをもう一度見たくなる→閉じたタブを開き直す　という操作をやるのだけれども、Tab Historyが入っていれば、子タブしか残っていない状態でも「戻る」ボタンで親タブで見てたページに戻れる。

ていうかソース覗いてみて思ったけど、これ作った人頭いいなー。タブが開かれる時に引数でリファラが指定されていたら現在アクティブなタブから開かれたタブであると見なしてセッションヒストリを引き継ぐ、という判定をしていて、最小限の変更で適切な動作になるようにしてる。まあリファラを偽装する系の他のアドオンと組み合わせた時には問題が起こるかもしれないけど。僕にもこういうピンポイントで問題を解決する力が欲しい。

あとPrint All Tabsにちょっと興味を引かれたので、マルチプルタブハンドラのタブ選択時のメニューに「選択したタブを印刷」を加えるようにしてみてる（Print All Tabsをバックエンドに使うので、Print All Tabsが入っていない場合は使えない機能となる）。

劣化品 - Dec 03, 2008

Ctrl-Tabとタブカタログを比較して良し悪しを語るのはいいんだけど、2年近く先行して開発された（一覧の表示方法を現行の形式に変更した時で比較しても、約1年先行）物をとっつかまえて、後から出た物の劣化品呼ばわりは、さすがに無いと思うんだ。「時代遅れ」なら許せる。

あと、タブカタログが劣化品と言うなら、Ctrl-Tabのサムネイルの上で右クリックした時にタブの上と同じコンテキストメニューくらい出して欲しいです。

コンテキストメニュー拡張の機能を減らした - Dec 02, 2008

コンテキストメニュー拡張を久しぶりにアップデートした……けどアップデートの内容は実質デグレードみたいなものだ。外部アプリケーションでソースを表示する機能、mailto:のリンクをメールソフトやWebメールのサービスに渡す機能、ユーザスタイルシートを編集する機能、任意のスタイルシートを登録して切り替える機能、あたりをゴッソリ削除した。

• ソースを他のアプリケーションで開く機能はFirefox 3本体にあるし、ソース表示タブあたりを使えばGUIで設定できる。もはや用済み。
• mailto:の処理をコントロールする機能もFirefox 3に標準で付いてる。オプション→プログラム→mailtoで、外部アプリケーションを指定することもYahoo!メールやGmailを指定することもできる。もはや用済み。
• スタイルシート関係の機能は、そもそもまともに動かなくなってからだいぶ経ってた。今ではStylishもあればuserstyle.orgもあり、そっち使った方が絶対にいい。

できれば無駄にRDFを使ってるバックエンドも全部捨てたいんだけど、これを捨てると旧版の設定が全部失われてしまうことになるというのが痛い。

Minefield 3.1b3preの、タブのドラッグ＆ドロップへの対応 - Dec 02, 2008

ツリー型タブとマルチプルタブハンドラで、Firefox 3.1からの「ウィンドウ外にタブをドロップしたら新しいタブを開く」機能に対応した。子タブを持っているタブをウィンドウ外にドロップしたら子孫タブまで含めて新規ウィンドウに分離され、複数のタブを選択してウィンドウ外にドロップしたら選択されたタブすべてが新規ウィンドウに分離される。という感じ。ちょっと前の分割ブラウザの更新もこれに関係してる。

Minefield 3.1b3preでは、ブラウザのタブをドラッグした時はapplication/x-moz-tabbrowser-tabという型のデータがドラッグデータのリストの先頭に加わるようになった。今までは、ドラッグセッションの「ドラッグを開始した要素」をその都度参照していたようだったので、やっとまともな実装になったなーという感じだ。

分割ブラウザやツリー型タブでは、この型のデータも受け入れ可能なように修正した。そうしておかないと、「application/x-moz-tabbrowser-tab型のデータはドロップできないんだな」と判断されて、タブをタブバーや分割された領域にドロップできなくなってしまう。

Minefield 3.1b3preでの「ウィンドウ外へのドロップ」はどのように実装されているのかを調べてみた所、dragendイベント（ドラッグが終了した時に、「ドラッグが開始された要素」で発行されるイベント）のタイミングで、ドロップ操作に失敗した（ドラッグ操作終了時点でポインタの状態が「ここにはドロップできません」のポインタになっている）場合には「ウィンドウ外へドロップされた」と判断して、新しいウィンドウを開きそのタブとドラッグ元のタブを入れ替える、という風にして実現していた。

この時ドラッグ元のウィンドウでは、tabbrowser要素の_replaceTabWithWindow()メソッドにおいて、新規ウィンドウの第1引数にtab要素を渡して開くだけで処理を終えている。そこから先の「ドラッグ元のタブと新しいウィンドウの内容の入れ替え」は、新しく開かれたウィンドウの初期化処理（BrowserStartup()関数）の方でやってる。

なので、ツリー型タブとマルチプルタブハンドラでは、その両方の処理に割り込むようにした。_replaceTabWithWindow()を呼び出している_onDropEnd()メソッドで、_replaceTabWithWindow()メソッドを呼ぶ直前に割り込んで、切り離されようとしているタブの収集結果がそのウィンドウのタブ全部だった場合には操作をキャンセルしている。また、BrowserStartup()の方では、ウィンドウの第1引数がtab要素だった場合はまずツリー型タブとマルチプルタブハンドラに処理を渡して、何も行われなければ（渡されたタブが子タブを持っておらず、選択もされていないならば）Firefox本来の処理（単一タブの切り離し）に入る、という感じにしている。

ドラッグ元のタブ自身の上にドロップした時までウィンドウの切り離しになってしまうなど、Minefield 3.1b3preの当該機能自体がまだまだ作り込みが甘い感じなんだけど、そういう所にまで手を出すと収拾がつかなくなる＆Firefox 3.1正式版までの間に手を入れられたらまた作業のやり直しになるので、そこら辺は基本的に放置してる。ただし複数のタブを同時に閉じようとした時の問題だけは、閉じるのに失敗したタブが永遠に閉じられなくなるなどの致命的な問題を引き起こすので、ツリー型タブの側で対処している（提出したパッチと同じ事をやってる）。

ルーラーバーでエンコーディングの違いに対応したよ - Dec 01, 2008

英語で書かれた障害報告のメールに返信する時にルーラーがひどくずれていたのが気になってたけど放置してた件について、ルーラーバー 0.3.2008120101で修正した。

今まで、ルーラーの表示サイズの基準には編集領域のdocument.documentElementのfont-sizeを使ってたけど、こちらはエンコーディングが変わっても値が変化しない。それに対して、document.bodyのfont-sizeは、エンコーディングごとのフォントサイズの違いの影響を受ける。ということでbodyの方の値を参照するようにしたら、ルーラーの間隔はおおむね正しいものになるようになった。

ただ、これでもカーソル位置の強調表示のずれは残る。フォントサイズだけでなくフォント自体もエンコーディングによって変わる可能性があり、フォントサイズだけ合わせても、実際の編集領域とカーソル位置検出用の非表示のフレームとでフォントが違ったら、ピクセル単位で位置を拾った時に微妙にずれが発生する可能性がある。そこで、非表示のフレームの方にもエンコーディングの変化を適用させるために、SetDocumentCharacterSet()のタイミングで非表示のフレームの方のエンコーディングも変更するようにした。エンコーディングの動的な変更の方法はこんな感じ。

// this.calculator は非表示のフレームのbrowser要素
var docCharset = this.calculator.docShell
      .QueryInterface(Components.interfaces.nsIDocCharset);
docCharset.charset = aCharset;
var webNav = this.calculator.webNavigation;
webNav.reload(webNav.LOAD_FLAGS_CHARSET_CHANGE);
var self = this;
this.calculator.addEventListener('DOMContentLoaded', function() {
   self.calculator.removeEventListener('DOMContentLoaded', arguments.callee, false);
   // 読み込みが終わった段階でルーラーの表示を更新する（カーソル位置の検出をやり直す）
   self.updateRulerAppearance();
}, false);

最後にリロードしないと表示が変わらない、のかな？（リロードしなかった場合の挙動については未検証）