Home > Latest topics

Latest topics > Firefox 3.1のスマートロケーションバーまわりがわけわからん！

宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ シス管系女子って何！？ - 「シス管系女子」特設サイト

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

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

  • 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 > Firefox, , , , , 時刻：13:41 | Comments/Trackbacks (7) | Edit

このカテゴリ以下の他のエントリ

  1. Goodbye, EdgeHTML（私的日本語訳）
  2. Casual cooperation of addons
  3. FirefoxとThunderbirdの導入案件で使ってるソフトウェアを公開し（て）た
  4. e10sオワタ
  5. Firefox Hacks Rebooted、オライリーから出ました

Comments/Trackbacks

海外でも似たような感想が

当ブログを参照していただいて、ありがとうございます。
mozilla.dev.apps.firefoxで、browser.urlbar.search.sourcesとbrowser.urlbar.default.behaviorの関係がわけわからんといってる人を見かけました。 ご参考までに。
http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/8a01e7e75314fef9#

Commented by Rockridge at 2009/01/10 (Sat) 02:07:41

no title

何で混乱するのか分かりました。
search.sourcesの方は、出発点の0が「検索ソースなし」＝「検索を無効にする」でフラグが増えれば増えるほど検索範囲が広がっていくのに対して、
default.behaviorの方は、出発点の0が「フィルタリングなし」＝「全てを検索の対象にする」でフラグが増えれば増えるほど検索範囲が狭まっていくということで、
認識が真逆なんですね。

この二つを統合するのなら、default.behaviorの方に統合した方がいい……というかそうせざるを得ない気がしてきました。
その上で、default.behavior用のビットの一つとしてDENY_ALLみたいなのを新設して、そのビットが立ってたらsearch.sources=0と同じと扱う、という感じにしたらいいんじゃないかなあ。
で、設定パネルのsearch.sourcesに対応してた項目は、default.behaviorの値を見てUIを初期化したり、UIの状態の変化に応じてdefault.behaviorのビットを立てたり寝かせたりする。みたいな。

ってこういう話はbugzillaに書けって感じですね。

Commented by Piro at 2009/01/10 (Sat) 09:59:08

no title

https://bugzilla.mozilla.org/show_bug.cgi?id=472943
ダメ元で。

Commented by Piro at 2009/01/10 (Sat) 10:26:18

私も混乱してきました

記事を再度読ませていただいたのですが、2点疑問に思ったところがあるので、質問させてください。
1点目。本文の最後から二番目の段落の、第二文目ですが、「前者が0（検索機能自体が無効になっている）以外で、後者が3の時は……」とあります。指示語をそのまま受け取ると、「前者」はbrowser.urlbar.default.behaviorを指すように見えますが、文脈からするとbrowser.urlbar.search.sourcesを指すように思われます。この文では、「前者」と「後者」を入れ替えるべきではないでしょうか。
2点目。Piroさんのコメントに、「search.sourcesの方は、出発点の0が『検索ソースなし』＝『検索を無効にする』でフラグが増えれば増えるほど検索範囲が広がっていく」とあります。たしかに、search.sources=1のときは履歴が検索対象に入ってくるので、範囲が広がったといえます。しかし、search.sources=2のときは、「『ブックマークされていて且つ履歴にも含まれている（＝訪問済みのブックマーク）』項目」が検索対象となり（orではなくand）、いったん広がった範囲が狭くなっているように思われます。フラグが増えれば増えるほど検索範囲が広がるとはいえないのではないでしょうか。
私も混乱していますので、誤解している点があれば遠慮せずご指摘ください。

Commented by Rockridge at 2009/01/10 (Sat) 14:19:33

no title

> 1点目。本文の最後から二番目の段落の、第二文目ですが

すみません、書き間違いでした。混乱がそのまま文章になってました。

> 2点目。Piroさんのコメントに、「search.sourcesの方は、出発点の0が『検索ソースなし』＝『検索を無効にする』でフラグが増えれば増えるほど検索範囲が広がっていく」とあります。

これは、数値が増えていくのではなく、ビット列として見た時に1になっているビットの数が増えていくことについて述べたつもりでした。
search.sources=0 => 00
search.sources=1 => 01
search.sources=2 => 10
search.sources=3 => 11
という感じです。

Commented by Piro at 2009/01/11 (Sun) 01:39:19

やっとわかってきました

説明してくださってありがとうございました。
私も混乱していて、search.sources=2が「10」ではなくて「11」になるような錯覚に陥っていましたが、ご説明のおかげで、ようやくわかってきました。
Bugzillaのコメントを見ると、3.1でロジックを付け足した結果がこのややこしい仕様のようですね。私のような素人の目から見ても、Piroさんのおっしゃるとおり、extra bitを加えてbrowser.urlbar.default.behaviorに一本化するのが簡潔な方法だと思います。

Commented by Rockridge at 2009/01/11 (Sun) 07:58:59

no title

The Burning Edgeに出てたバグ一覧に、本文で触れた部分についてのバグがありました。

Bug 426864 – Only show user typed history pages for the urlbar dropdown

https://bugzilla.mozilla.org/show_bug.cgi?id=426864


Bug 463459 – Use a separate pref instead of empty restrict/match values to specify defaults

https://bugzilla.mozilla.org/show_bug.cgi?id=463459

Commented by Piro at 2009/01/12 (Mon) 09:18:32

TrackBack ping me at


の末尾に2020年11月30日時点の日本の首相のファミリーネーム（ローマ字で回答）を繋げて下さい。例えば「noda」なら、「2009-01-09_awesomebar.trackbacknoda」です。これは機械的なトラックバックスパムを防止するための措置です。

Post a comment

writeback message: Ready to post a comment.

2020年11月30日時点の日本の首相のファミリーネーム（ひらがなで回答）

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2～2005.8

最近のコメント

旧コンテンツ

最近のつぶやき