[feature-request]: Restrict auto-completion feature in Firefox url-bar for different domains

[Martin Nemec]

Binary package hint: firefox

The url-completion in FF3 is a great feature. However for some domains the feature should be restricted. Let me explain:
For web-sites where a page id is given in the url (e.g. websites based on typo3 or joomla!) the whole list of pages on this domain are suggested upon typing in the url bar. For such domains where one may like only to go to the home page a feature should be introduced to restrict the auto-completion for this domain (-> only domain respectively the link to the home page should be suggested...)

This is true for FF3

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

[Davidpjames (davidpjames)]

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.

[Davidpjames (davidpjames)]

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

[Torstenvl (torstenvl)]

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

[Bugs-bengoodger (bugs-bengoodger)]

Big Fun with history and autocomplete coming after 1.0

[Mike Connor (mconnor)]

no means no :)

[Ocean-acloakinthewood (ocean-acloakinthewood)]

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

[Ivan Icin (ivanii)]

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?

[Ocean-acloakinthewood (ocean-acloakinthewood)]

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.

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

[Mano-mozilla (mano-mozilla)]

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

[Jake031 (jake031)]

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

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

[Ocean-acloakinthewood (ocean-acloakinthewood)]

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?

[Mano-mozilla (mano-mozilla)]

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

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

[Ocean-acloakinthewood (ocean-acloakinthewood)]

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

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

[Ocean-acloakinthewood (ocean-acloakinthewood)]

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

[Davidpjames (davidpjames)]

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.

[Jake031 (jake031)]

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

[Psellhorst (psellhorst)]

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

[Gavin Sharp (gavin-sharp)]

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

[Janzert-haskincentral (janzert-haskincentral)]

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

Brian

[Janzert-haskincentral (janzert-haskincentral)]

Sorry, Bug #128341

Brian

[Rparenton (rparenton)]

(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

[Gavin Sharp (gavin-sharp)]

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

[Robeddielee (robeddielee)]

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

[nikitas (neonile)]

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!

[Brettw-gmail (brettw-gmail)]

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

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

[Brettw-gmail (brettw-gmail)]

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.

[Brettw-gmail (brettw-gmail)]

The patch to bug 320181 was the fix.

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

[Brettw-gmail (brettw-gmail)]

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.

[Pkasting (pkasting)]

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

[Dtownsend (dtownsend)]

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

[Mano-mozilla (mano-mozilla)]

Created attachment 266430
the backout

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

[Mano-mozilla (mano-mozilla)]

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

[Olli-pettay (olli-pettay)]

Because of the attachment 266430 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

[Mwu-mozilla (mwu-mozilla)]

attachment 266430 also crashes my build when just typing in an URL.

[Mano-mozilla (mano-mozilla)]

Looking...

[Mano-mozilla (mano-mozilla)]

Created attachment 266495
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

[Mano-mozilla (mano-mozilla)]

Created attachment 266499
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

[Chrisbloom7 (chrisbloom7)]

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

[Chrisbloom7 (chrisbloom7)]

I second my idea.

[Martin Nemec (spocky)]

Binary package hint: firefox

The url-completion in FF3 is a great feature. However for some domains the feature should be restricted. Let me explain:
For web-sites where a page id is given in the url (e.g. websites based on typo3 or joomla!) the whole list of pages on this domain are suggested upon typing in the url bar. For such domains where one may like only to go to the home page a feature should be introduced to restrict the auto-completion for this domain (-> only domain respectively the link to the home page should be suggested...)

This is true for FF3

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

Thanks for your report, that's something that needs to be send to https://bugzilla.mozilla.org/, for forwarding instructions please have a look to https://wiki.ubuntu.com/Bugs/Upstream/Mozilla ; thanks.

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

Found the regarding bug upstream and linked it here.

[Michaelkohler-linux (michaelkohler-linux)]

is this still wanted?

[Chrisbloom7 (chrisbloom7)]

I still think it would be a welcome improvement.

[Nemo_bis (nemobis)]

Similar bug, almost a dupe: bug 96700.

[Jboriss (jboriss)]

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

[Signupper (signupper)]

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.

[Vova (vovaolar)]

Bug 240397 is a duplicate

[Vova (vovaolar)]

of Bug 409271

[Dao (dao)]

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

[Bugzilla-kennel17 (bugzilla-kennel17)]

Adding my voice - this is something that bugs the crap 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!

[Jaws (jaws)]

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