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: :) :)

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 :)

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.

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

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! \(^.^)/

Big Fun with history and autocomplete coming after 1.0

no means no :)

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. :)

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?

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.

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.

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

(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).

(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.

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?

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

(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.

(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.

>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.

(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.

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.

(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 ;-)

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

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

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

Sorry, Bug #128341 Brian

(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

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

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

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!

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

(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.

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.

The patch to bug 320181 was the fix.

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.

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.

(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.

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"?

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

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

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

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

Looking...

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

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

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

I second my idea.

is this still wanted?

I still think it would be a welcome improvement.

Similar bug, almost a dupe: bug 96700.

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.

Bug 240397 is a duplicate

of Bug 409271

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!

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