Closed Bug 661359 Opened 13 years ago Closed 6 years ago

Location bar autocomplete should notice if I start typing a URL and match accordingly

Categories

(Toolkit :: Places, enhancement, P5)

1.9.1 Branch
x86
Windows XP
enhancement

Tracking

()

RESOLVED INACTIVE

People

(Reporter: stephen, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14

I realize many people won't type "http://" or similar in a Web browser, but for those of us who do, it would be useful if the location bar's autocomplete function didn't bury URLs which begin the same as what you type somewhere down the list.

BTW, I'm posting this as core because I've verified that both Seamonkey 2.0.14 and Firefox 4.0.1 show the same behaviour.

Reproducible: Always

Steps to Reproduce:
1.  Populate your history by visiting a number of Web sites including http://toronto.ctv.ca/, http://www.toronto.ca/, and anything with "Toronto" in its <title>
2.  In the Location bar, type "http://toronto"
3.  View results

(Obviously, this is not specific to Toronto; I'm just using that as an example because it's the case that made me notice this.)

Actual Results:  
All of the sites you visited with the text "toronto" anywhere in their URLs or <title>s will appear, just as if you'd typed "toronto" rather than "http://toronto" in the Location bar, and the one that actual begins with "http://toronto" is (as far as I can tell) *never* at the top of the list

Expected Results:  
Sites whose URLs actually match the URL fragment you typed should be first on the list.

(You could make a case that, logically, only URLs which exactly match the portion you typed should be on the list, but I think it's more useful for the others to appear as well in case you thought you wanted "http://toronto.something.whatever" but it was actually "http://something.toronto.whatever")
> I've verified that both Seamonkey 2.0.14 and Firefox 4.0.1 show the same
> behaviour.

That doesn't mean it's a core issue... ;)  It just means they have the same code for it.
Component: General → Location Bar
Product: Core → SeaMonkey
QA Contact: general → location-bar
http://mxr.mozilla.org/comm-central/source/suite/browser/browser-prefs.js#181

181 // The special characters below can be typed into the urlbar to either restrict
182 // the search to visited history, bookmarked, tagged pages; or force a match on
183 // just the title text or url.
184 pref("browser.urlbar.restrict.history", "^");
185 pref("browser.urlbar.restrict.bookmark", "*");
186 pref("browser.urlbar.restrict.tag", "+");
187 pref("browser.urlbar.restrict.openpage", "%");
188 pref("browser.urlbar.restrict.typed", "~");
189 pref("browser.urlbar.match.title", "#");
190 pref("browser.urlbar.match.url", "@");

So if you typed @http://toronto ... does this do what you want?
160 // 0: Match anywhere (e.g., middle of words)
161 // 1: Match on word boundaries and then try matching anywhere
162 // 2: Match only on word boundaries (e.g., after / or .)
163 // 3: Match at the beginning of the url or title
164 pref("browser.urlbar.matchBehavior", 1);

Or you could go into about:config and set browser.urlbar.matchBehavior to 3.
(In reply to comment #2)

Should a user have to read the source code looking for special characters in order to get the browser to match what you actually typed instead of only matching part of what you typed?

I can understand why a special character is necessary in order to restrict the search to (say) bookmarks or history, since there's nothing in what the user would type otherwise that would signify that.  But if the user types protocol://something, obviously they're looking for a matching URL, and shouldn't have to add a special character to say so - particularly since (for those of us who've been using the Web for more than a couple of years) this is the behaviour that older, dumber browsers typically did automatically.
(In reply to comment #3)

If I read the mozillazine KB description correctly, this changes the behaviour for all matches, not just matches that look like URLs - so if I set that preference, it breaks most of the awesomeness of the awesome bar, which is not what I'm suggesting.

(I'd imagine that the reason it's exposed only through about:config, not the regular UI, is because it comes with a high price in functionality; I think it's fair for this one to require a user to go under the hood to change it.)
I'm going to move this to toolkit since the backend code which handles this is shared with Firefox.
Component: Location Bar → Places
Product: SeaMonkey → Toolkit
QA Contact: location-bar → places
Version: unspecified → 1.9.1 Branch
(In reply to comment #6)
> I'm going to move this to toolkit since the backend code which handles this
> is shared with Firefox.

(and also in reply to comment #1):  thanks for shuffling this into a more appropriate place than I found.
It's very confusing even to insiders. The visible location bar UI in Firefox and SeaMonkey is different and we have our own display code for this. However the magic code that generates the list of 'awesomebar' autocomplete matches lives in shared backend code. We send what you type to the backend and we don't have any control (other than the preference settings) over what we get back.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.