This would map directly to the dropdown for the privacy prefpane without stealing/overriding/losing values of other preferences.
Created attachment 346920 [details] [diff] [review] v1 Create a pref with 4 states and tests to make sure it works.
Comment on attachment 346920 [details] [diff] [review] v1 r=me, with the dependency on bug 463459 removed. thanks, this is much clearer for users than the default.behavior pref.
Created attachment 347012 [details] [diff] [review] v1.1 Just use mRestrict* instead of SET_BEHAVIOR.
Comment on attachment 347012 [details] [diff] [review] v1.1 This is needed for privacy prefpane bug 460343. Has tests too!
What parts, if any, of bug 447900 comment #3 does this obsolete? I fear we're running into some pref mess in the long term here...
I was about to say bug 463459 would better cover the issue of empty == default behavior. But then reading bug 447900 comment 3, it seems like there's a desire to turn off the behavior entirely. (Bug 463459 provides a bitmap to turn on.. say, "match by title" by default; the default behavior is no filters.) It kinda sounds like there should be a tri-state pref in addition to the filter-word pref: 1) always use this filter 2) use the filter if <filter-word> is used 3) never use this filter even if filter-word is used
If I am reading this bug correctly the new pref browser.urlbar.search.sources does not include an option to only search tags. Is this intentional? The options seem to be bookmarks, history or both. Seeing as there is a filter pref browser.urlbar.restrict.tag does it not make sense to have a value for search.sources that defaults tags only?