"AwesomeBar" is totally NOT awesome

[fswl1234]

Here's a build that allows you to specify an empty keyword:

https://build.mozilla.org/tryserver-bui ... l.urlonly/

Change your about:config preference to have match.url be "" instead of "@" and everything you type should be matching in the url.

i just tried and it seems to be working as suggested: urls only
are these prefs & their values documented somewhere? i'd like to read more and see if i can tune it further

thanks for your work and i hope it gets adopted by the final

[Mardak]

Here's a build that allows you to specify an empty keyword:
https://build.mozilla.org/tryserver-bui ... l.urlonly/

Change your about:config preference to have match.url be "" instead of "@" and everything you type should be matching in the url.

i just tried and it seems to be working as suggested: urls only
are these prefs & their values documented somewhere? i'd like to read more and see if i can tune it further

Well, only in that bug and in posts on my site. But what do you mean by tune?

The values you set are a character (or a word) that you want to use to specify to start using that "restrict" or "match".

So you could do something like "browser.urlbar.match.title" set to "dah" and when you type words in the location bar.. "forums mozillazine" will match in the url and title and tags.. but if you type "forums mozillazine dah", it'll match "forums mozillazine" only in the title.

It also works for characters like 任 if that's what you prefer.

The only special character is "" (no character) which makes it apply that restrict/match by default.

[fswl1234]

But what do you mean by tune?

although it's urls only, the results returned are still different from what's in 2.0
i think it's the way urls are matched, used to check only the host part (not sure) and now any where in the whole url?

[minotaur 11]

@Mardak

The reusing of previous search results is already very useful, but a correction of the search text starts always a complete new search. I often remove some of the last typed characters to correct a typo, or to get more useful results. Would it be possible to temporary save the last e.g. three searches and to reuse them in such cases?

[Mardak]

But what do you mean by tune?

although it's urls only, the results returned are still different from what's in 2.0
i think it's the way urls are matched, used to check only the host part (not sure) and now any where in the whole url?

Right. It'll match anywhere in the url (on a word boundary). So even if you set "match.url" to "", you can still type "for moz 23" to find the Firefox Builds forum.

[Mardak]

The reusing of previous search results is already very useful, but a correction of the search text starts always a complete new search. I often remove some of the last typed characters to correct a typo, or to get more useful results. Would it be possible to temporary save the last e.g. three searches and to reuse them in such cases?

That point about getting more results is interesting. So you type one too many characters that results in nothing and you want to back up.

Hrmm........... Perhaps instead of saving the last 3 searches, it could checkpoint itself every several characters, so if you search for "mozillazineeeee", it might have checkpointed "mozil" instead of "mozillazineeee", "mozillazineee", "mozillazinee".

Interesting idea.

[iwod]

This so call Awesome bar is actually a nice idea that needs more polishing. I think people hate it simply because they are not getting the results they want.

If i type neowin, i actually want Neowin.net first before all those Neowin Forum post that keeps at the top of selection.
Similar to forums.m - if i type that i expect forums.mozillazine.org first before all the post of mozillazine i have visted before.

Second set of results that comes below the above mentioned ones should be similar results that are in my bookmarks. If there are none list them in the order that i have visited most , then ones i recently visited.

Because currently 9 times out of time i have to scroll through the list to get my results.

I also wonder if the Results headline / topic should be bold type or coloured. So it would be more eyes catching.
I mean does anyone even look at the url address? Personally if i cant find the topic title i want i would check URL address and then do others things that get my results.

[minotaur 11]

That point about getting more results is interesting. So you type one too many characters that results in nothing and you want to back up.

Yeah, i often know which result i want to get, but i'm not sure of the right search terms. For example i search for a bug with "bugz slow scrolling" and if i get not the right result, i change the search to "bugz slow page" and so on. The correction of a typo is however the most frequently case for me, in this case the last three searches would be often enough to avoid a complete new search.

[Mardak]

I filed bug 424673 for you.

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=424673">Bug 424673</a> – Optimize AwesomeBar for correcting typos or removing terms that caused no results

[Frank Lion]

On the functionality side of the urlbar autocomplete dropdown (named 'awesome' by some Mozilla toady) something like this would be useful :



1. Reduce entries showing to 5. Mainly to lower the impact of the damn thing waving in your face every time you are trying to enter a web address.

2. Position Bookmark Star and Tag icons directly underneath the site favicon, so that the eyes do not have to flick sideways to determine if that entry is a bookmark/tag/history or search, by origin. Good UI functionality revolves around these sort of details.

3. Introduce horizontal scrolling and stop trying to kid users that truncating url entries does not matter. This point relates to :

4. Awesome Bar - the removal of the ability to untruncate the url and also the loss of the ability to horizontally scroll that box, has meant a user has to check each full Url address via Tooltip alone. There are many users, not me though, who search by Url address alone, life could have been made easier for them by not removing this functionality in early February.

Originally, the way to do this was to leave .ac-title hidden so as to not upset star/tag positions, the urlbar width often giving you full title anyway. Then visible !important the .ac-url. Combine that with commenting out the overflow-x hidden stuff and you had full url with a single horiz scroll at the bottom of the whole box. I would suggest that this would enhance functionality to this generally useful new feature.

...that was originally mentioned here. The full entries then easily being checked like so :

[fadsxcv]

So you could do something like "browser.urlbar.match.title" set to "dah" and when you type words in the location bar.. "forums mozillazine" will match in the url and title and tags.. but if you type "forums mozillazine dah", it'll match "forums mozillazine" only in the title.

Why were those weird semantics chosen? My (and I'm guessing everyone else's) natural intuition is that it works like this:

Assume there are only 3 keywords:
# - search only in titles
@ - search only in urls
$ - search only in history (i.e. not bookmarks)

foo <-- this does the default search. Since no keywords are empty, it searches everything
foo # <-- ditto
foo # bar <-- narrows down the above search by looking for bar in the titles
foo # bar @ moz <-- narrows down the above search by only urls that contain moz

(Though I'd probably prefer readable search engine style tags better like title:foo bar tags:bar)

[Mardak]

Here's a new build with the cached searches:

https://build.mozilla.org/tryserver-bui ... ty.search/

1. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=424673">Bug 424673</a> - Optimize AwesomeBar for correcting typos or removing terms that caused no results
2. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=418257">Bug 418257</a> - Show what part of which tags match for urlbar autocomplete
3. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=392143">Bug 392143</a> - show keywords as url bar autocomplete choices
4. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=249468">Bug 249468</a> - Add all bookmark keywords to location bar autocomplete drop-down list
5. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=395161">Bug 395161</a> - Make it possible to restrict the url bar autocomplete results to bookmarks/history entries and match only url/title/tags
6. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=420437">Bug 420437</a> - Search and emphasize quoted strings with spaces
7. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=422698">Bug 422698</a> - different levels of URL decoding for address bar and autocomplete suggestions
8. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=423942">Bug 423942</a> - "Clear List" in download manager should be "Clear Current List" during the search
9. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=423718">Bug 423718</a> - Use native platform colors for URLs in the location bar autocomplete, make the line between rows lighter
10. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=414326">Bug 414326</a> - Use DownloadUtils for software update downloads
11. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=424557">Bug 424557</a> - Allow AwesomeBar to default search only urls (or history/titles/bookmarks/tags)

edit: updated link

[Mardak]

Why were those weird semantics chosen?

It's to keep with the current "typing more keeps restricting results", but it was originally designed for restricting and not forcing matches. "search word" .. too many results from bookmarks "search word ^" .. only have history items.. continue searching "search word ^ match"

[minotaur 11]

I filed bug 424673 for you.

Bug 424673 – Optimize AwesomeBar for correcting typos or removing terms that caused no results

Wow... Thank you!

Not related to the awesomebar, the permissions of the tryserver build for linux are wrong:
$ tar -tjvf edward.lee@engineering.uiuc.edu-cached. ... nux.tar.bz2
drwx------ 0/0 0 2008-03-23 20:40 firefox/
-rw------- 0/0 0 2008-03-23 20:39 firefox/.autoreg
-rwx------ 0/0 160068 2008-03-23 20:40 firefox/libssl3.so
drwx------ 0/0 0 2008-03-23 20:40 firefox/res/
-rw------- 0/0 18967 2008-03-23 20:40 firefox/res/unixcharset.properties
...

[fadsxcv]

Why were those weird semantics chosen?

It's to keep with the current "typing more keeps restricting results", but it was originally designed for restricting and not forcing matches. "search word" .. too many results from bookmarks "search word ^" .. only have history items.. continue searching "search word ^ match"

The weird semantics I was referring to was that the operator picks the crap on the lhs as the operand as opposed to the thing on the rhs i.e. you basically implemented Reverse Polish Notation. I find that it's A. way too hard to reason about when writing a query and B. not in the natural order people are used to with search engines like "site:mozilla.org filetype:pdf"

I can't really see people typing stuff and then going "whoops, no, I meant that I wanted restrict what I just typed to only search in the tag field". It seems more likely to me that they start with the thought "okay, now I want to search the tags using this query string" instead.


Speaking of which, how about implementing something like this:

When you hold down the ctrl key when the urlbar has keyboard focus, replace all the entries in the urlbar completion list with a list of all the keywords and a brief description of what it does. When the ctrl key is released, the entries revert back to the old list. If an entry was selected it will be pasted where the caret was.

This way A. keywords are more likely to be discoverable and B. it serves as a sort of cheatsheet (with autocompletion) so we don't have to memorize the arbitrary keyword list.