Closed Bug 424557 Opened 16 years ago Closed 16 years ago

Allow AwesomeBar to default search only urls (or history/titles/bookmarks/tags)

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.1a1

People

(Reporter: Mardak, Assigned: Mardak)

References

(
URL
)

Details

Attachments

(1 file, 2 obsolete files)

v1.2
1.99 KB, patch
Details | Diff | Splinter Review 
A common request is to have the location bar only match in the url by default.

A second request is to only match history -- unbookmarked pages.

Potentially people would also only want to search titles by default or only bookmark/tags. (Perhaps a kiosk that has a set list of bookmarks?)
Attached patch v1 (obsolete) — — Splinter Review 
This makes it so if you specify the "special search" to be an empty keyword, it'll automatically use it.

So if you set "browser.urlbar.match.url" to be "" instead of "@", it'll always only search urls by default.
Assignee: nobody → edilee
Status: NEW → ASSIGNED
Attachment #311174 - Flags: review?
Blocks: 422944
How about not showing anything when you type data in on the location bar.  There should be a way to stop this from happening.  It is a pure waste of CPU and very very annoying!
(In reply to comment #2)
> How about not showing anything when you type data in on the location bar. 
> There should be a way to stop this from happening.  It is a pure waste of CPU
> and very very annoying!
> 

"Setting the preference to 0 effectively disables the Location Bar dropdown entirely."

http://kb.mozillazine.org/Browser.urlbar.maxRichResults
Don't suppose this will make it for Fx3? I know there's a small number of users out there who really don't like their bookmarks being searched.
(In reply to comment #4)
> Don't suppose this will make it for Fx3? I know there's a small number of users
> out there who really don't like their bookmarks being searched.

I'm supportive, but this patch requires bug 395161, which isn't blocking, and the Places team is pretty busy fixing blockers atm.
Flags: blocking-firefox3?
Way too late to block on added features.
Flags: blocking-firefox3? → blocking-firefox3-
(In reply to comment #2)
> How about not showing anything when you type data in on the location bar. 
> There should be a way to stop this from happening.  It is a pure waste of CPU
> and very very annoying!
> 

This will make it show only what you are typing & not drop down.
> set browser.urlbar.matchOnlyTyped to true
> set browser.urlbar.maxRichResults to 0
> set browser.urlbar.search.chunkSize to 0

Keeping privacy concerns in mind, please consider allowing to opt out the bookmarks from appearing in url list during installation itself! Many people may end up realizing, to their horror or embarrassment, the expose awsomebar can create at the most inappropriate moments!
Blocks: 440740
There are a lot of users (like me) who don't like the way awesomebar works and wish you could, in effect, make it behave like FF2.

The Hide Unvisited 3 add-on does this. Read the comments on that add-on to see what some users think of awesomebar.

https://addons.mozilla.org/en-US/firefox/addon/7429

Type "about:config" in the address bar (sans quotes) and hit enter. You can click through the warning about voiding the warranty (that is an inside joke... there is no warranty). In the "Filter" spot at the top of the page, type in "browser.urlbar", again, without the quotes. Double-click on the entry that shows up that says "browser.urlbar.maxRichResults" and change the number from 12 to 0. Then close Firefox and start it back up again. That should essentially turn that feature off.

that took care of the problem
Flags: wanted-firefox3.1?
Attached patch v1.1 (obsolete) — — Splinter Review 
Unbitrot from bug 395161 landing with restricts on history/bookmark/tag and match for title/url.
Attachment #311174 - Attachment is obsolete: true
Attachment #330362 - Flags: review?(dietrich)
Attachment #311174 - Flags: review?
(In reply to comment #11)
> Type "about:config" in the address bar (sans quotes) and hit enter. You can
> click through the warning about voiding the warranty (that is an inside joke...
> there is no warranty). In the "Filter" spot at the top of the page, type in
> "browser.urlbar", again, without the quotes. Double-click on the entry that
> shows up that says "browser.urlbar.maxRichResults" and change the number from
> 12 to 0. Then close Firefox and start it back up again. That should essentially
> turn that feature off.
> 
> that took care of the problem
> 

I'll be careful, I promise.
How creative.
Comment on attachment 330362 [details] [diff] [review]
v1.1

r=me, thanks!
Attachment #330362 - Flags: review?(dietrich) → review+
Attached patch v1.2 — — Splinter Review 
Get rid of unnecessary reset to PR_FALSE and add testcases.
Attachment #330362 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/index.cgi/rev/88bbab534518

Those using Hide Unvisited add-on won't need it for 3.1 and instead just need to change browser.urlbar.restrict.history to "".
URL: https://addons.mozilla.org/en-US/fire...
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1a1
Changing about.config has ALWAYS been the option. However the key issue here arises out of the default behavior and non disclosure during installation! 

Say Bob has a default installation of FF3 on his HTPC. He has a cache of some ummm... interesting bookmarks. Friends come over and would like to check something online. They start typing in the awsomebar and the dropdown suddenly shows up the most unexpected results on his high def 52" screen TV! 

And Bob doesn't even know what hit him for his bookmarks were last thing he expected anyone to check and in any case, he had hidden them well in a deep hierarchy of folder! And whats more, he had even cleaned up his browsing history before the friends arrived!

So again, the issue is not merely having an option in about.config. It's about letting the user know during installation, or immediately after creation of a new profile, that not only his/her browsing history (which is a default in most browsers including FF2, hence a generally expected behavior!) but also his bookmarks will start appearing in the awsomebar, along with a single click opt-in/out!
(In reply to comment #18)
> Changing about.config has ALWAYS been the option. However the key issue here
> arises out of the default behavior and non disclosure during installation! 

That's not this bug, about:config could only turn search off till this bug landed, not pick out between history and bookmarks. Single bugs tend to cover very specific issues so it's easy to refer to a check list of what has and hasn't been done rather than general ideas.

If you want to propose behaviour changes for Firefox either make a new bug or post a design proposal at mozilla.dev.apps.firefox which can be easily done here: http://groups.google.com/group/mozilla.dev.apps.firefox/topics
This seems to be doing nothing about removing bookmarks from the drop-list of the AwesomeBar

Setting browser.urlbar.restrict.history to "" <- bookmarks still appear even with a new profile, and clearing history.  
Setting browser.urlbar.restrict.bookmark to "" < same as above bookmarks still shown.

Could someone post the expected syntax of the pref's and explain how its expected to work ?  

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008072203 Minefield/3.1a1pre Firefox/3.0 ID:2008072203

Should this be re-opened or another bug filed against this one?
I believe this patch has had a serious performance impact on Autocomplete.  Typing in one letter and starting to see results used to almost 'instant', now its taking 2+ secs to show anything... 


I think a documentation for end-users is needed.
Keywords: user-doc-needed
I second Littlemutt concerning the performance issue. 

But the landing really works:
setting browser.urlbar.restrict.history to "" hides the non-history bookmarks from being shown, and vice versa for restrict bookmarks/tags.
I think the best way to have this option, would not only be in about:config, but also in Options, for the typical user (Grandma Factor). Have it selected to earch bookmarks by default, and make it easy to find to turn off. Privacy, or Main would be a good home for that option.
I agree. Choosing it at installation is too much IMO, but an option in UI is useful, since much people requested this bug fixing.
I see this has been marked as "FIXED". Does this mean that it is fixed in the target milestone, i.e. 3.1a1?

If so, how exactly is it fixed in that version?
(In reply to comment #27)
> I see this has been marked as "FIXED". Does this mean that it is fixed in the
> target milestone, i.e. 3.1a1?

Yes. See http://ed.agadak.net/2008/07/firefox-31-restricts-matches-keywords
Hmm, am I right that in the default case for a toolkit application with --enable-places, i.e. where no prefs are set at all (currently happens when you compile SeaMonkey with --enable-places and get places history there, not places bookmarks btw), you end up matching nothing as all those prefs are empty?
What if we add an additional restriction type and the pref is missing, do we then match only that type by default, ignoring the others?
Robert: you might be interested in bug 447900.
Flags: wanted-firefox3.1? → wanted-firefox3.1+
I'm only using places history, not bookmarks. Can I turn off special handling of ^ * and + and always autocomplete from history?
Verified FIXED using:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b1pre) Gecko/20080913115846 Minefield/3.1b1pre

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080913031911 Minefield/3.1b1pre

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080913020424 Minefield/3.1b1pre

Although I didn't test every possible combination, on each platform, I did pair testing while following http://ed.agadak.net/2008/07/firefox-31-restricts-matches-keywords; also, this has automated tests.
Status: RESOLVED → VERIFIED
Blocks: 447900
Blocks: 462692
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: