240397 - Location-Bar auto-complete should favor top-level URLs (should put top-level domain at the top of the list)

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, enhancement)

Description

[Alexander Ewering]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8

Hello!

The auto-completion in Firefox's location bar is far from usable most of the
time. For example, if I have visited www.endless-fantasy.de, and browsed around
the page a lot, the next time I open Firefox, it will show all kinds of
"sub-URLs" from that page as soon as I enter "endl", but the MOST IMPORTANT link
- the index page (just www.endless-fantasy.de) is lost somewhere in the middle
of the stack of URLs, and one has to scroll down through dozens of entries to
find it.

It's much quicker to just type the whole URL by hand then :)

It should definitely auto-complete the most top-level URL by default.

Reproducible: Sometimes
Steps to Reproduce:
See above!
Actual Results:  
:)

Expected Results:  
:)

:)

Comment 1

[Mike Connor [:mconnor]]

David can clarify on this since I'm sure he knows more about the bugs in
question, but I think this is a dupe.

In any case, IIRC typed URLs take precedence, then by most accessed, some of
this might be post-0.8 though.  0.8 was basically done before Christmas, other
than some cleanup, so I might be muddying things, but I found the most commonly
used/typed options when I tested this, so you might want to try a current
nightly build :)

Comment 2

[David P James]

I'm surprised that this isn't a dupe but after an extensive search of all open
and even resolved and verified autocomplete bugs I can't find a dupe.

Comment 3

[David P James]

*** Bug 240694 has been marked as a duplicate of this bug. ***

Comment 4

[Josh Ockert]

I'm gonna be bad and comment without getting the latest nightly (I'm on 0.8
release) but perhaps *all* typed entries should be shown? That way people can go
back to quick searches and so on.

Actually, it might be cool to have *only* typed entries show up in the location
bar, and then at the bottom have an entry to open up your full history... would
keep it (location bar) cleaner and easier to navigate, plus, if someone did want
a non-typed entry, those entries would also be better-organized, as per the
users history view settings :)

Just a thought. Thanks!  \(^.^)/ 

Comment 5

[Ben Goodger (use ben at mozilla dot org for email)]

Big Fun with history and autocomplete coming after 1.0

Comment 6

[Mike Connor [:mconnor]]

no means no :)

Comment 7

[ocean]

I'm using FireFox 0.9, and it would appear that the URL Bar History is being
sorted by most recently visited, rather than alphabetically.

I use FireFox with Inline Autocomplete turned on - and the intuitive way for
this to work is that the addresses come up with the closest match to what you're
typing in - which is usually alphabetical in nature.  Basically - this should
work the same way that the URL Bar history and Inline Autocomplete works in
Internet Explorer.


As an example, in Internet Explorer if I type "forums.mozilla" I'll get
"forums.mozillazine.org". If I keep typing until I reach
"forums.mozillazine.org/pos", then I.E. might autofill
"forums.mozillazine.org/posting.php". 


However, if I'm in FireFox, and I type "forums.mozilla", it might pull up
"forums.mozillazine.org/posting.php?mode-newtopic%f=31" simply because I might
have accessed that page more recently than I accessed "forums.mozillazine.org". 



To me, this seems backwards.  Or, at the very least - the sort options should be
user-definable.  That's my take on it, anyway.  :)

Comment 8

[Ivan Ičin]

I like the way Auto-complete now works (as I get it it first shows the most
frequently visited pages).

For example, I read news on one local site and I don't need to see home page
www.b92.net, but the news page that is longer URL which I would be never able to
remeber.

I think that it is enough to choose once or twice the page you want, and later
it will be on top always. Did you try this?

Comment 9

[ocean]

The problem, Ivan, is that the current implementation causes more problems 
than it solves - for some people.

I'm not arguing completely against the current implementation - I just think 
that as a compromise to moving over completely to eh alphabetical approach, 
perhaps it should be a user option.  

Comment 10

[Prognathous]

Bugzilla doesn't currently support voting against bugs, so let me just chime in
and say that from my own usage pattern, the current implementation would be more
effective. Favoring top level domains will probably cause more harm than good.

To get some solid data about the way other users handle the URL autocomplete,
check Nisheeth Ranjan's research:
http://www.mozilla.org/projects/ml/autocomplete/ac-report.html

Prog.

Comment 11

[Asaf Romano (gone)]

count me in the against list...top-level URLs use Bookmarks.

Comment 12

[Jake]

(In reply to comment #11)
> count me in the against list...top-level URLs use Bookmarks.

And all other URL's you've been to are in your history, so you might as well
argue to use that.

I, personally, go to bookmarks with the mouse and use AutoFill/Autocomplete with
my keyboard.

Favoring of top-level domains has little impact if you do not want to go to the
top-level, but has 'a lot' of impact if you do. You would be able to use the
right arrow to complete the toplevel domain and start typing 'after the slash'.

To compare it with IE: it just completes the url as far as the next slash, so
you automatically get top-level domains.
For going to: www.fake_url.com/firstfolder/secondfolder/destination.file
you type: 'www.fa' [right] 'f' [right] 's' [right] 'd' [enter]
Or you select it from the list, if you see it sooner.

Where with FF if you hapen to have gone to www.fake_url.com/some.file
you'd have to type (at least) 'www.fake_url.com/f' [enter]

IMHO autofilling the URL to anything but a top-level domain is much more
inconvenient, because you have to type (a lot) more (or scroll a lot down the list).

Comment 13

[Prognathous]

(In reply to comment #12)
> Favoring of top-level domains has little impact if you do not want to go to
the top-level, 

It has a lot of impact on me, it breaks something that currently works very very
well.

> but has 'a lot' of impact if you do.

Just trim one of the results so that you're left with the top level domain. If
you do that often enough, it should be at the top of the list.

> To compare it with IE: 

Please don't bother. I've used IE's URL autocomplete. It blows donkeys. Compared
to Mozilla and Firefox, it can take dozens of additional key-presses to get to a
 page/site.

> IMHO autofilling the URL to anything but a top-level domain is much more
> inconvenient, because you have to type (a lot) more (or scroll a lot down the
list).

You really should try to trim a URL once or twice, it would work wonders to the
order of your autocomplete URLs.

Notwithstanding the above, I wouldn't mind if the top level domain was included
somewhere in those first 6 results - as long as it's not the first one. This
should remain based on actual usage.

Prog.

Comment 14

[ocean]

You guys are arguing needlessly over this.  There is no one right answer 
here.  Some people want alphabetical sorting, others want it based on History 
and useage.

Stop beating each other with "My way is better!", "No, *my* way is better!".

It all comes down to the fact that different people use their browsers 
differently.

What I suggest is that it simply be made into a user option - so that you can 
switch it to whichever one you prefer.

Doesn't that make the most sense?

Comment 15

[Asaf Romano (gone)]

Do you *really* think someone is going to accept gui for this? :-)

Comment 16

[Prognathous]

(In reply to comment #14)
> It all comes down to the fact that different people use their browsers 
> differently.

This could be a reason to implement gazillion of other fringe options, yet we
don't want that. Why? because there are certain absolutes in GUI design. When
one method is measurably more efficient for practically any user and requires
less keystrokes, there's no need to bloat our interface with needless alternatives.

It would be a good idea, however, to fine-tune the current method. That's what
efforts like bugs 182366 are for. They can measurably reduce about a keystroke
of each autocomplete event. This is where we should be heading, not IE's way.

Prog.

Comment 17

[ocean]

(In reply to comment #16)
> This could be a reason to implement gazillion of other fringe options, yet we
> don't want that. Why? because there are certain absolutes in GUI design. When
> one method is measurably more efficient for practically any user and requires
> less keystrokes, there's no need to bloat our interface with needless  
> alternatives.

It's more "efficient" to use passwords of only one character.  Certainly, it's 
fewer keystrokes.  So why bloat the interface with a field that can take more?

You have a couple of things going on here.  First of all, the fact that there 
is arguing about this bug in the first place shows you that you can't blithely 
make the claim that it's effectively better for most users.  And you can't 
argue efficiency either - because that is largely a subjective matter when it 
comes to browser useage.

Why?  Well, you're arguing for the whole "reduced keystroke" deal.  But that 
is based on a useage model of URLs being sorted by History, rather than 
alphabetically.  However, if I am visiting a URL that is not the most recently 
accessed, or the most used - I have to type significantly more than I 
otherwise might.  

In addition, there is no practical way to anticipate what the URL bar is going 
to come up with.  You can guess - but you can't know.  If it's sorted 
alphabetically, however - I don't even have to look at the URL bar.  I know 
exactly what's going to come up - and in exactly what order.  And even if I do 
have to look - the order is intuitive.  If you know where you're going, you 
know where on the list to find it.  If the URL bar sorts by History, however, 
the link you're looking for could be *anywhere*.

So, to me - alphabetical sorting is significantly more efficient.  I don't 
have to guess, I don't even have to look, and if I do have to look - I know 
exactly where to find the address I want.


So, I can argue effiency at least as well as you, or anyone else.  What does 
this mean?  It means that it's worthy of making into a user-controllable 
option.


Seperate from that, I don't see how you can argue against choices.  Isn't one 
of the founding principles of FireFox to have significant customizability?  
Firefox allows you to enable or disable AutoFill in the first place, as well 
as Dialog Box Errors, and a whole slew of options.

Going by your argument, we could probably cut out 70% of what Firefox allows 
you to do.  The problem is that what is efficient for you and your workflow 
doesn't necessarily apply to everyone else.


And for what it's worth, I disagree strongly that giving users options 
qualifies as bloatware.  **As long as they follow the theme of what the 
program is designed to do.**  Give a hundred, a thousand, ten thousand 
different options for how you can customize your browser.  To me, that does 
NOT qualify as bloatware - because it's all related to the primary function.  
However, once you start packaging in an FTP client, Usenet reader, IM client, 
etc... - THAT qualifies as bloatware, because it's additions that have nothing 
to do with the primary function of being a browser.

So, please - add as many options as you can for FireFox.  With each added way 
a user can make it work as *they* want to - whether it's more efficient or 
not - you'll get more people flocking to use FireFox as their browser of 
choice.

Comment 18

[Mike Connor [:mconnor]]

>First of all, the fact that there is arguing about this bug in the first place 
>shows you that you can't blithely make the claim that it's effectively better 
>for most users.

Minority users are especially good at both arguing incessantly and persistently
for their chosen method.  Three or four people in a user population of millions
is incredibly insignificant in terms of gauging user response.

If you don't understand why unlimited prefs are bad, you don't have a clue why
the Phoenix project was founded.  Most users (generally studies come in around
75%) don't touch prefs, so choosing a default method is key.  Supplementary to
that is the fact that supporting multiple methods of sorting/displaying options
is more code.  If 50% of the users that even touch prefs (which is certainly a
very high estimate) want alphabetical order, that's still 12.5% of your
userbase.  That means 87.5% are paying a price in bloat for a feature they will
never use.  That's bloat to most people.

Alphabetical sorting is a terrible concept, and does nothing to adapt, and the
more you visit a site, the more it makes the list unusable.  You can argue until
you're blue in the face, but lousy application logic will not go into Firefox,
especially if it adds code.

The more I read of this bug, the closer to WONTFIX it becomes.

Comment 19

[ocean]

(In reply to comment #18)

> Minority users are especially good at both arguing incessantly and 
persistently
> for their chosen method.  Three or four people in a user population of 
millions
> is incredibly insignificant in terms of gauging user response.


Despite what you might claim, the fact is that the majority of users still use 
IE.  People are used to it, and a large percentage of that userbase will not 
even consider moving to another browser if it's incapable of duplicating IE's 
functionality and look.  Better or worse, the average user tends to stick with 
what they're used to, and if you don't understand that - you should do a 
little catching up on history and marketing research.

That being the case, *FireFox* users are the "three or four people" in 
the "user population of millions" who run IE by comparison.  If minority users 
weren't worth attending to, Firefox would never have been born.


> If you don't understand why unlimited prefs are bad, you don't have a clue 
why
> the Phoenix project was founded.  Most users (generally studies come in 
around
> 75%) don't touch prefs, so choosing a default method is key.  


Than make whatever decision you feel is best for the *default* value.  But 
don't take away the user's option to change it.


> Supplementary to
> that is the fact that supporting multiple methods of sorting/displaying 
options
> is more code.  If 50% of the users that even touch prefs (which is certainly 
a
> very high estimate) want alphabetical order, that's still 12.5% of your
> userbase.  That means 87.5% are paying a price in bloat for a feature they 
will
> never use.  That's bloat to most people.


Most users are accustomed to browsing errors showing up in the browser 
window.  They don't like every single 404 error popping up as a Dialog Box, 
being forced to click OK  each and every time (talk about inefficient).  Heck, 
even FireFox users find that feature extremely annoying.  But it's still in 
there, the code was implemented, and it's currently set as the default value.

In light of that, I would hardly think that you should argue sort preferences, 
as it doesn't even begin to compare with the uselessness, inefficiency, and 
annoyance factor of Dialog Box errors.

Besides which, although you and many others argue against the value of 
integrating multiple sorting options - I still note quite a bit of annoyance 
over FireFox's inability to sort Bookmark Folders at the top of the list, 
seperate from the individual bookmarks themselves.  Obviously, someone thought 
that doing a true unbiased alphabetical sort was a good idea - but that 
doesn't keep Firefox users all around the world from saying "What the heck!" 
in frustration for not having the OPTION to change that behavior.  

However, I don't see you telling these people that they're statistically 
insignificant, and therefore shouldn't complain and ask that more "bloat" be 
added.  Most software applications contain options that the majority of users 
will never touch.  But that doesn't mean that those options shouldn't be 
there.  If it did, Adobe Photoshop wouldn't be able to do a tenth of what it 
can.


> Alphabetical sorting is a terrible concept, and does nothing to adapt, and 
the
> more you visit a site, the more it makes the list unusable.  You can argue 
until
> you're blue in the face, but lousy application logic will not go into 
Firefox,
> especially if it adds code.
> The more I read of this bug, the closer to WONTFIX it becomes.


Alphabetical sorting may be a terrible concept *for you*.  Don't make the 
tragic mistake of making the naive decision that what's best for you is best 
for everyone else.  I am not a fan of alphabetical sorting simply because I'm 
blindly accustomed to it.  I have logical reasons why it works for me and why 
it is a superior and more efficient way of navigating.  If your workflow is 
different - that's okay.  I respect that.  But all I'm asking is that you give 
others the same courtesy and not demean and diminish methods that are 
different than yours.

After all, IE users are still the undisputed majority.  Firefox users are 
without question, a minority by comparison.  And just as that fact shouldn't 
keep you from trying to make a better browser - don't ignore other users just 
because they might also be on the minority side of things.

Comment 20

[David P James]

Good grief. What do any of alphabetical or historical or preponderance of use 
sorting have to do with this bug? This one is about favouring the top-level 
url, as Jake illustrates in comment #12. I suppose that what you do after 
you've got to the top level is up for debate (I lean towards preponderance of 
use) but really if I'm going to bugzilla I want bugzilla.mozilla.org and not 
one of the hundreds of bugs I've visited to be the first thing that comes up 
when typing 'bugz...'. The same thing goes for all those sites that put 
session-specific stuff into the url (and your much vaunted average user will 
go about using the bloody backspace key to get rid of all that crud the next 
time she visits the site). 
 
I think using the Tab key might be a little preferable to the Right key that 
Jake mentionned, but that's probably because I'm used to Linux command-line 
autocomplete. 

Comment 21

[Jake]

(In reply to comment #20)
> I think using the Tab key might be a little preferable to the Right key that 
> Jake mentionned, but that's probably because I'm used to Linux command-line 
> autocomplete. 

At present: tab selects the first (next) item from the list and the right key
functions as I mentioned.
If 'we' change the tab key, all Hell would break loose ;-)

Comment 22

[psellhorst]

See also bug 96700 (Autocomplete should offer "base" server address first).

Comment 23

[:Gavin Sharp [email: [e-mail]]]

*** Bug 274843 has been marked as a duplicate of this bug. ***

Comment 24

[Brian Haskin (Janzert)]

This is probably a dup of Bug #128431 although firefox wasn't around at the time
it was filed.

Brian

Comment 25

[Brian Haskin (Janzert)]

Sorry, Bug #128341

Brian

Comment 26

[Robert Parenton]

(In reply to comment #24)
> This is probably a dup of Bug #128431 although firefox wasn't around at the time
> it was filed.
> 
> Brian

Firefox has different autocomplete code than the Suite, so this is not a dupe

Comment 27

[:Gavin Sharp [email: [e-mail]]]

*** Bug 305058 has been marked as a duplicate of this bug. ***

Comment 28

[Robert Lee]

*** Bug 327178 has been marked as a duplicate of this bug. ***

Comment 29

[Nikitas Liogkas]

I'm proud to annouce the public release of version 1.0 of the Autocomplete Manager, which fixes this bug by means of an extension! The extension provides advanced features for the address Autocomplete framework in Firefox. Features include:
- matching against page titles
- matching against bookmark addresses and bookmark names
- matching any part of the domain name
- various sorting criteria for suggested entries, including alphabetical, most-frequently-visited and most-recently-visited
- resorting the suggestion list on the fly according to different criteria
- showing/hiding page titles and visit counts
- setting the number of visible entries on the popup
- define the truncation for long addresses
- numerous fixes for Autocomplete-related bugs

The extension can also function as a rudimentary History Manager. More details, as well as the installation package, are available at http://www.cs.ucla.edu/~nikitas/acmanager

Please let me know of any suggestions/bugs.

Thank you!

Comment 30

[Brett Wilson]

*** Bug 267780 has been marked as a duplicate of this bug. ***

Comment 31

[Prognathous]

(In reply to Mike Connor, comment #18)
> Alphabetical sorting is a terrible concept, and does nothing to adapt, and the
> more you visit a site, the more it makes the list unusable.  You can argue
> until
> you're blue in the face, but lousy application logic will not go into Firefox,
> especially if it adds code.
> 
> The more I read of this bug, the closer to WONTFIX it becomes.

Please do, before it's too late ;-)

Prog.

Comment 32

[Brett Wilson]

On 1.8 branch and trunk when places is enabled.

Here's the behavior: the results will be generated and scored. Then we look at the top result and see if it has a path. If it does, we strip it off and add a new entry above it containing just the host name. We only do this if the top item has been visited few times. If the top item has been visited many times, we assume you really want that one and don't strip the path.

Comment 33

[Brett Wilson]

The patch to bug 320181 was the fix.

Comment 34

[Mike Connor [:mconnor]]

We're going to reopen this abd back out brettw's fix, it causes problems with inability to delete history entries (via Delete, Shift+Delete on Mac), since they're not actually history entries.  This has some merit, and the heuristic is actually fairly sane, but it interacts poorly with a longstanding behaviour.  There is merit in giving toplevel domains URLs some extra weighting instead of creating an extra entry (i.e. visits * 1.5 to help keep it higher in the rankings) as an alternate which works for not breaking deletion of history entries while pushing toplevel URLs higher in the stack.

Comment 35

[Brett Wilson]

Why not delete the real entry that it was created from instead? That would have the same effect while keeping the much nicer domain suggestion feature. Backing out this useful change seems a bit drastic, IMO.

Comment 36

[Peter Kasting]

(In reply to comment #34)
> We're going to reopen this abd back out brettw's fix, it causes problems with
> inability to delete history entries (via Delete, Shift+Delete on Mac)

How many people delete history entries via shift-delete vs. are helped by the domain suggestion?

I have no numbers, but my gut feeling would be that you'd be hurting a lot more people than you're helping with this move, given that out of the dozens of people I've told about shift-delete (one of my favorite features), I was the only one who'd known it was there.

Brett's suggestion is a good compromise.  If you don't want "nytimes.com" in your history it's a good bet you don't want the one page at nytimes.com that you visited there, either.

Comment 37

[Dave Townsend [:mossop]]

Personally I think the feature is a fantastic one, however I think deleting the one page you've visited at a site is a really really bad idea. You are removing part of a users personal data that they weren't expecting to be deleted.

A couple of thoughts:

Could we somehow flag domains that the user has not wanted to see in autocomplete? (probably a bit overcomplicated).

Why can't we handle this the same as the search box. There we have two parts of autocomplete, the history (which is deletable) and the suggestions (that is not). Presumably we aren't having similar problems there? Why not label the top level domain as a "Suggestion"?

Comment 38

[Asaf Romano (gone)]

Attachment: the backout

this also remove TYPE_BOOKMARK check now that the id field for bookmarks & folders is unified.

Comment 39

[Asaf Romano (gone)]

Checking in src/nsNavHistoryAutoComplete.cpp;
/cvsroot/mozilla/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp,v  <--  nsNavHistoryAutoComplete.cpp
new revision: 1.10; previous revision: 1.9
done

Comment 40

[Olli Pettay [:smaug][[e-mail]]]

Because of the attachment 266430 [details] [diff] [review] trunk crashes now when copy-pasting 
an URL to the location bar
#0  0x00002aaaaaff707a in nsAString_internal::Equals (this=0x11c1e98, str=@0x28011c1e70)
    at /home/smaug/mozilla/mozilla_cvs/mozilla/xpcom/string/src/nsTSubstring.cpp:632
#1  0x00002aaab370ee88 in nsNavHistory::AutoCompleteFullHistorySearch (this=0xc39b00, aSearchString=Variable "aSearchString" is not available.
)
    at /home/smaug/mozilla/mozilla_cvs/mozilla/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp:501
#2  0x00002aaab370f253 in nsNavHistory::StartSearch (this=0xc39b00, aSearchString=@0x1195238, aSearchParam=Variable "aSearchParam" is not available.
)
    at /home/smaug/mozilla/mozilla_cvs/mozilla/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp:328
#3  0x00002aaab7b27790 in nsAutoCompleteController::StartSearch (this=0x11951d0)
    at /home/smaug/mozilla/mozilla_cvs/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp:1001
#4  0x00002aaab7b278cd in nsAutoCompleteController::Notify (this=0x11951d0, timer=Variable "timer" is not available.
)
    at /home/smaug/mozilla/mozilla_cvs/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp:688
#5  0x00002aaaaafcec42 in nsTimerImpl::Fire (this=0x1574920) at /home/smaug/mozilla/mozilla_cvs/mozilla/xpcom/threads/nsTimerImpl.cpp:386
#6  0x00002aaaaafcf1d7 in nsTimerEvent::Run (this=0x1141bb0) at /home/smaug/mozilla/mozilla_cvs/mozilla/xpcom/threads/nsTimerImpl.cpp:456
#7  0x00002aaaaafca41a in nsThread::ProcessNextEvent (this=0x530900, mayWait=1, result=0x7fffb0bdca3c)
    at /home/smaug/mozilla/mozilla_cvs/mozilla/xpcom/threads/nsThread.cpp:482
#8  0x00002aaaaaf6c65f in NS_ProcessNextEvent_P (thread=Variable "thread" is not available.
) at nsThreadUtils.cpp:227
#9  0x00002aaab111c870 in nsBaseAppShell::Run (this=0x60ef30) at /home/smaug/mozilla/mozilla_cvs/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:154
#10 0x00002aaab159972a in nsAppStartup::Run (this=0x6d70f0) at /home/smaug/mozilla/mozilla_cvs/mozilla/toolkit/components/startup/src/nsAppStartup.cpp:171
#11 0x00002aaaaab11313 in XRE_main (argc=dwarf2_read_address: Corrupted DWARF expression.
) at /home/smaug/mozilla/mozilla_cvs/mozilla/toolkit/xre/nsAppRunner.cpp:2817
#12 0x0000000000400718 in main (argc=Variable "argc" is not available.
) at /home/smaug/mozilla/mozilla_cvs/mozilla/browser/app/nsBrowserApp.cpp:69

Comment 41

[Michael Wu [:mwu]]

attachment 266430 [details] [diff] [review] also crashes my build when just typing in an URL.

Comment 42

[Asaf Romano (gone)]

Looking...

Comment 43

[Asaf Romano (gone)]

Attachment: crash fix

Somehow this doesn't crash on OS X.

Checking in toolkit/components/places/src/nsNavHistoryAutoComplete.cpp;
/cvsroot/mozilla/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp,v  <--  nsNavHistoryAutoComplete.cpp
new revision: 1.11; previous revision: 1.10
done

Comment 44

[Asaf Romano (gone)]

Attachment: argh

Checking in toolkit/components/places/src/nsNavHistoryAutoComplete.cpp;
/cvsroot/mozilla/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp,v  <--  nsNavHistoryAutoComplete.cpp
new revision: 1.12; previous revision: 1.11
done

Comment 45

[Chris Bloom]

44 comments - ack! I'm gonna be daft and just comment without reading them all. 

I was going to file this bug if i didn't find a dup. I support the original request - sort auto-complete alphabetically based on history. Could be toggled to current functionality based on about:config entry. 

Perhaps as a one-up: Sort based on domain tree, i.e. http://www.mysite.com/apple/ comes before http://www.mysite.com/about.html... Would allow for a kind of hybrid auto-complete like the TAB-based auto-complete in Windows command shell.

Example: I want to go to http://whoa.this.is/a/long/url/eh.html

I type "http://w" (or maybe just "w" to see ftp and https entries as well)

Auto-suggested: All domain names starting with w*, arranged alphabetically
http://way.too.go/
http://whoa.this.is/
...
http://www.alltheweb.com/
http://www.bagpipes.org/
...

I down-arrow to the first entry and key TAB, which puts the text into the address bar and puts the cursor at the end, then continue to type "a":
http://whoa.this.is/a

Auto-suggested:
http://whoa.this.is/a/
http://whoa.this.is/abigail/
http://whoa.this.is/about.html
http://whoa.this.is/ack.html

If I then type "b":
http://whoa.this.is/ab

Auto-suggested:
http://whoa.this.is/abigail/
http://whoa.this.is/about.html

Arrow key to the first and TAB and I can keep typing to get suggestions further up the tree. Arrow-key to the second and I can key ENTER to go, or TAB to keep typing (perhaps to add some querystring data)

* I willingly accept all insults for not reading previous comments

Comment 46

[Chris Bloom]

I second my idea.

Comment 47

[Michael Kohler [:mkohler]]

is this still wanted?

Comment 48

[Chris Bloom]

I still think it would be a welcome improvement.

Comment 49

[Federico]

Similar bug, almost a dupe: bug 96700.

Comment 51

[Sign]

I really hope someone works on this, it's been my biggest pet peeve with Firefox for years. When you start typing a url, the auto-complete sort order is consistently never what you want, which is most likely the homepage. To get around it, I resort to bookmarking sites that I would otherwise not want to, and by reloading the homepage a bunch of times, just to boost the sort order. Over time, the homepage still doesn't always make it to the top, sometimes it gets stuck in position #2 or 3.

Comment 52

[Vova Olar]

Bug 240397 is a duplicate

Comment 53

[Vova Olar]

of Bug 409271

Comment 55

[Mark Clements]

Adding my voice - this is something that bugs the **** out of me!  So much time is wasted editing long URLs (Bugzilla URLs being a particularly common example) just to get to the home-page!!  Easier to type the whole damn thing by hand!

Comment 56

[Jared Wein [:jaws] (please needinfo? me)]

This was basically implemented by enabling the Location Bar autofill feature in bug 735187. The autofill feature completes to the top level URL.