Closed Bug 78268 Opened 23 years ago Closed 23 years ago

should urlbar auto-complete matching urls as you type?

Categories

(SeaMonkey :: Location Bar, defect)

Product:
SeaMonkey
Component:
Location Bar
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: hewitt, Assigned: hewitt)

References

Details

Attachments

(2 files)

patch to autocomplete binding to behave like IE autocomplete
4.97 KB, patch
Details | Diff | Splinter Review
test xul file to try out autocomplete binding behaviour
3.25 KB, text/plain
Details 
It's a tough call - when the user types, should we place matching autocomplete
urls in the urlbar and highlight the inserted portion, as we have traditionally
done?

This will probably require some user-testing and/or perhaps some prefs in order
to get it right.  Let the debate begin.
Status: NEW → ASSIGNED
i'll be the first to chime in. IE will fill in the rest of the url for you, quite 
effectively i might add. we should follow their lead. It's also very annoying to 
have to "down-arrow" a bunch to get something that is almost always the correct 
answer.

Nay.  The current behavior is safe, because the user has to either type in the
URL exactly, or pick it from the list.  The previous behavior meant that a user
trying to visit a substring of something in the history had to use the backspace
key to get what he wanted, else Mozilla might wisk him off to the wrong page.
Nay.  The current behavior is safe, because the user has to either type in the
URL exactly, or pick it from the list.  The previous behavior meant that a user
trying to visit a substring of something in the history had to use the backspace
key to get what he wanted, else Mozilla might wisk him off to the wrong page.
Component: XP Apps → URL Bar
QA Contact: sairuh → claudius
*** Bug 78287 has been marked as a duplicate of this bug. ***
I forgot to throw in that currently, tab-completion works in the URL bar, so if
you just want mozilla to fill in the shortest match, you currently can do that
with tab.  There is of course a long precedent for tab completion, and I'm
personally quite fond of it.
Can I add a request that stuff like http:// not be autocompleted? It doesn't
really offer any benefit, and the old urlbar code had a list of entries it
wouldn't try and complete for you.
um, how can tab-completion be expected to work if "tab" moves focus out of the 
url bar? if it doesn't then that's a serious bug. cc'ing aaronl

Okay, so there are some rough edges.  It looks like the tab is moving focus to
the drop-down, not completing like the shell.  Bummer.  Also the matching is not
that great.  When I type "www.arstechnica", the first 500 matches are at
"arstechnica.infopop.net", and "www.arstechnica.com" is dead last.  Needs work.
Personally I would like to have this feature back (saves some keyboard actions),
perhaps prefable as hewitt suggested.
Nay. This is a duplicate of bug 40305, which was fixed for the original
auto-complete widget -- see also the problems with in-line auto-completion 
described in bug 51910. If in-line auto-completion was introduced into the new 
auto-complete widget, that would be a regression.
As mentioned before fine-tuning, usability testing and observing how actual
users use it once released is "the other 90%" of development time. This goes for
autocomplete vs drop down as well as determining what the most valuable entry is
for the 90% of users case. Joe and I will be doing more finetuning on the
matching behavior. This is work in progress.
In the mean time we I suggest adding prefs for those who prefer to turn all
things "auto..." off or to only have the old behavior (best guess autocomplete).
So hang on, it will get better as we battle-test it and with the help of your
feedback.
*** Bug 78477 has been marked as a duplicate of this bug. ***
Oh yeah, it definitely should auto-complete matching URLs as you type. The drop 
down is nice if you have a number of URLs that are similar, but the auto 
matching is what saves you time in the general case. I really miss the "type a 
little bit, have it autocomplete, and press Enter". The down arrow just doesn't 
feel as smooth/obvious.

I could see this being a pref. Turning off the dropdown box and keeping 
effectively the same auto complete as in NS 4.x may be desireable.
*** Bug 78477 has been marked as a duplicate of this bug. ***
my vote is yes.  while the autocomplete dropdown is fine and dandy as it is, the 
inline behavior is a less obtrusive, and much less jarring alternative for users 
who are not in the "power" class.

german@netscape.com, is there a tracking bug for general completion problems? 
e.g. typing "news.gnome" and getting "news.com" as a match? (actually I think
anything that looks like it starts with a scheme is busted).
Most URLs that users type are short ones (the front page of a site).  If I have 
visited an inner page of a site (via a link from somewhere -- fairly common) and 
I then try to go to the front page, the old autocomplete behavior makes my life 
hell -- I have to hit enter in a tiny little time-window.  This can be somewhat 
alleviated by giving preference to the shortest matching string, perhaps... but 
even then it'll only work if you've visited the front page already.

Also, the new completion seems to be matching against anything in history, not 
just things we've typed in the URL bar before.  Is this really what we want?  
Eliminating that behavior may make fill-in much less noxious.

*** Bug 51412 has been marked as a duplicate of this bug. ***
*** Bug 78950 has been marked as a duplicate of this bug. ***
I entered one of the duplicate bugs.  My wife HATES the way IE works for
autocomplete.  When I showed her mozilla she really loved it.  Now I am stuck
with ****... yes ****... in fact it reaks of MS ****.  Let me back to my nice
old mozilla way and get rid of this IE **** and maybe we will soon pick up
another user (we would have her sans some stability issues).

Again, it should autocomplete... sure give a list too, but make it autocomplete
to the shortest... if two are shorter... give the first with the other at the
top of the drop down list
I agree with Trever. If there's considerable disagreement, a pref would be good. 
How about:

---Location Bar Autocomplete-------------------------------
Automatically completes text entered into the Location Bar.

[X] Enable Location Bar Autocomplete
    (O) Show list of suggestions and fill in best match
    ( ) Show list of suggestions only
    ( ) Fill in best match only

Of course, we have to decide what "best" means: shortest, most visted, most 
recenltly visted etc. Maybe another pref. Like this, perhaps:

---Location Bar Autocomplete-------------------------------
Automatically completes text entered into the Location Bar.

[X] Enable Location Bar Autocomplete
    (O) Show list of suggestions and fill in best match
    ( ) Show list of suggestions only
    ( ) Fill in best match only

    Rank suggestions by:
    (O) Length of address (e.g. mozilla.org comes before mozilla.org/projects)
    ( ) Time since last visit (pages visited more recenlty will appear first)
    ( ) Number of visits (most frequently visted pages will appear first)

I'm working on the assumption that length of address actually ranks by domain 
and path. So typing "www.z" would list "www.zdnet.com, 
www.zisthelastletterofthealphabet.com, www.zdnet.com/zdnn", even though 
www.zdnet.com/zdnn is shorter than www.zisthelastletterofthealphabet.com 
(because www.zdnet.com/zdnn is a domain and path, while 
www.zisthelastletterofthealphabet.com is a domain only).
Spam: I appear to have major issues spelling "recently". Apologies.
Prefs are good... yes, definitely good.

I also beg everyone to consider bug 40305 (which was _finally_ fixed just before
the new autocomplete landed) when deciding what to do.

Of course, if URL bar autocomplete is added and it's as slow as it was before I
don't really care how it bahaves cuz it never kicked in anyway. For the longest
time I thought the functionality had been removed until 40305 was fixed :-)
I agree with Alex Bishop.  I don't really believe time last visited will be
useful, but number of times and length of url (Being done by length if the
domain + path has the same components, being done by # of compenents elsewise).

Good thoughts Alex!
*** Bug 80497 has been marked as a duplicate of this bug. ***
------- Additional Comments From Masato@gmx.de 2001-05-16 05:22 -------
I love the new way of search (especially showing the page's title)
But if you can switch it between old & new would be the best solution.

BTW: Autocomplete should take effect 500 milliseconds after stop typing.
     (At usual you type the begin of the URL and then the autocomplete is
useful, not earlier in the most cases)
BTW2: a UNIX-Shell like autocomplete with [TAB] would be great
      ex: you have only "www.startrek.com" & "www.starwars.com" in your 
history.
Then typing "www.s" press [TAB] and it will complete to "www.star" (Both 
entries
aren't alike then anymore.) 
      This UNIX-Shell like autocomplete should progress automatically until it
reach a "/"  or the history-entries start to differ

------- Additional Comments From timeless 2001-05-16 08:38 -------
<tab> is already overloaded, would people mind if <right arrow> did what people 
want tab to do?

tab jumps to content area [or sidebar].  Right arrow from the last character 
would usually do nothing, but if you had a selection (which we kind of do) it 
would step into/through it.
Like I said before... the autocomplete is supposed to save time and work.  All
this [Tab],[Left Arrow] is simply chunt.  If people don't like having it
acutally offer (automatically) a match, then find a way to turn it off for them.
 Stop making the rest of us work at it!
*** Bug 81540 has been marked as a duplicate of this bug. ***
Personally on the autocomplete I'm in favor of the most visited page being used 
as the autocomplete.

I think the drop down and auto complete should both have check boxes offered 
in the preferences. That way people can choose which one they want, or none at 
all. Some people I know don't like either way of auto complete.

Personally I'll stick with Netscape 4.77 if real auto complete is not added to 
mozilla/NS 6. It's to much work to start typing, then move my hand to the mouse, 
very counter intuitive. Yes, I know you can also press the down key. I don't 
want to go back to the Netscape 3 way of doing things where I have to type in 
the full URL even if I go to the page 3 times a day.

I suggest that interested developers take a look at galeon.  They embed mozilla,
and they also implement autocomplete.  There's works really well IMHO.  It
shadow complete's as far as it can uniquely in your history.  So if you have
slashdot and slackware, it will complete up to sla until you type past that.  If
you press tab, a drop-down appears with all possible matching candidates, and
the cursor is moved past the definite part of the match.

The only thing I don't like about this scheme is that you have to use the delete
key if you want to type a subset of a URL that you have typed before.
let's not play w/ historical user behavior here. IMO, it needs to work the way
4.x used to do it. in it's present form, I can never use it because I'm not
willing to hunt down the arrow keys on whatever random machine I'm on just to
get autocomplete to work.

requesting 0.9.1. this is equal to broken auto-complete IMO.
Keywords: 4xp, mozilla0.9.1
I'm with Jud. I want the old auto-complete behaviour back.

I prefer it this way to the old way (drop down rather than autocomplete).  So my
vote goes for either prefs, or staying this way and not regressing.
Aki, I'd argue the current model is a regression.

I'm all for pref'ing it, default to the old 4.x way.
I prefer the new auto-complete behavior.  I always hated the 4.x completion 
behavior.  The new system matches IE's autocomplete behavior (and I'm willing 
to bet they did usability studies that showed users were confused by the 
automatic completion).

The reasons I don't like the old way of autocomplete:
  1) i can't turn it off (so prefs would be acceptable)
  2) it invariably chooses the wrong url to complete,
  3) when i pause typing for a second, it highlights the entire url, so when i
continue typing i overwrite the previously typed portions,
  4) redirect urls don't seem to be memorized (at least in 4.x) so for instance
going to espn.go.com/nfl (which redirects you to
http://football.espn.go.com/nfl/index i believe), it always autocompletes to
some long url that i don't want and i have to hit the delete key (but *before*
it highlights the entire url, which it will do if i pause at all, or i have to
start over).

so i would consider going to 4.x behavior as regression.
Let's not forget the new autocomplete is also designed/useful for people new to
Netscape 6.x/Mozilla as they are able to discover that inline search is
available from the url bar.
FYI the current spec can be found at
http://mozilla.org/projects/ui/communicator/browser/search/
It is mentioned in there somewhere that the plan is to have prefs to do either:
a) full autocomplete and drop down list (default on)
b) just first match autocomplete
c) no autocomplete at all
Seems pretty clear that we need some user feedback here to decide on a final
implementation.  I think a pref is a good idea, but we still need some data to
decide what the default for that pref should be.

The idea of autocompleting in the least aggressive way (versus first match in
history), combined with the existing drop-down seems like a good one.  I would
suggest this behavior as a candidate for default behavior.
It looks like we're never going to come to a satisfactory decision, so I think a
pref is needed. After that, we'll have to decide which option should be the
default, but that can be put off for now.
Why is it that people always praise Microsoft for this or that?  If this
alternative is so great, go use it, use I.E.  Out of about 20 people I have
surveyed they all prefer the Netscape 4.x behavior and detest the I.E. behavior.
 It confuses them (i.e. method) and takes more time.

Microsoft may do usability studies, but I bet you will find that those who use
software products alot fall outside of Microsoft's studies quite often.  Don't
say Microsoft is flawed so we will make our own software... especially since
there are always those who wish to do the same STUPID design decisions as others.

Autocomplete has always been about making things easier and faster... THIS MEANS
MINIMUM MOUSE AND KEYBOARD ACTIVITY... YET WE ARE MAKING AUTOCOMPLETE SO COMPLEX
AND REQUIRE AT LEAST TWO KEY PRESSES AND A MOUSE MOVEMENT.  Get real or go work
for Microsoft and follow THEIR BAD DECISIONS THERE!
> If this alternative is so great, go use it, use I.E.

In case you haven't noticed, people already are. By the tens of millions. If 
you don't mind, I'd actually prefer it if Mozilla wasn't just a niche browser 
for use by those who disagree with Microsoft on principle.

> YET WE ARE MAKING AUTOCOMPLETE SO COMPLEX AND REQUIRE AT LEAST TWO KEY
> PRESSES AND A MOUSE MOVEMENT

That's not true. You don't have to touch the mouse at all. And you only need to 
do one (1) extra key press (the Down arrow key), in exchange for saving 
yourself several key presses from not having to type the rest of the URL. Just 
like in tab-completion for a Unix shell, where you need to do one (1) extra key 
press (the Tab key), in exchange for saving yourself several keypresses from 
not having to type in the rest of a filename. And the vast majority of users 
won't have Judson's problem of wondering where their Down key is, because 
they'll only be using one computer at a time. (Perhaps we should stop using 
Control+N to open a new window, because the position of the Control key varies 
on various keyboards? No? I thought not.)

Remember, 4.x didn't have an auto-complete menu at all. So claiming that our 
avoidance of 4.x's inline auto-completion is a `regression' is as silly as 
claiming that our introduction of a global history window (as opposed to 4.x's 
session history window) is a `regression'. 4.x only did inline auto-completion 
because it didn't have the toolkit ability to do anything better.

I'm not much concerned with whether this should be a pref -- if it was, it 
would only be one checkbox, and there's room in the History panel of my prefs 
spec for such a checkbox. But even if you found an understandable way to word 
it, the proportion of users who were annoyed by overzealous auto-completion AND 
who could find and use the pref effectively would be absolutely miniscule. So 
what the default setting should be is a far more interesting issue; and for 
those users who don't know that there's a pref, or who don't know where to find 
the pref, or who just can't be bothered stuffing around with the prefs instead 
of going back to IE, I believe that inline auto-completion is considerably more 
annoying than useful.
For those that didn't know, Tab and Shift+Tab will cycle down or up the list of
potential matches in the popup just as the up and down arrows will.  This is an
easier key combo for me because I already have tab autocomplete muscle memory
from terminal use.
my mom doesn't know what a terminal is.. explain that to her :)

Ditto the "using the tab key is cool." I probably wouldn't use the autocomplete
menu very often if I had to use the arrow key but, with the tab key working to
cycle through it (similar to using tab in bash), I think it's a really cool feature.
so we have 3 access methods for items on the autocomplete popup.  we can tab to
the correct item, we can arrow down to it or we can click it with the mouse. I
can't remember if someone already suggested this here, in one of the dupes or in
email but what about adding a 4 method, automatically inline autocompleting what
would have been the first item of the popup list and shifting all the popup
items up one (or leaving the first item in the popup and highlighting it). Tab
and arrows could have the same results, doing the inline autocomplete against
the next item in the popup shifting the list up each click (or just moving the
selection down in the popup). The mouse click already behaves differently in
that it does the selection and the "enter" which loads that selection.  The
autocompleted piece of the URL string would always stay selected so that further
typing would delete it and resume at the last manually entered character. (or
something like that). 
two comments:

- tab is already used to tab out of the url bar to the next focusable element.
bzzzt.

- mpt stated only 1 keypress was required. i totally disagree. 99% of the time,
the true completion of the site that i want is buried under other matches at the
same site, usually at the bottom of a long list. i have to hit 4-5 keystrokes on
average to do the correct completion.
i just added my vote to this bug, in hopes of the old auto complete returning.
My votes carries no weight but i thought i would note my preference.
> 99% of the time, the true completion of the site that i want is buried under
> other matches at the same site, usually at the bottom of a long list. i have to
> hit 4-5 keystrokes on average to do the correct completion.

In that case, in-line auto-completion would be useless 99 % of the time --
because the best guess of the in-line auto-completion would be exactly the same
as the best guess of the auto-complete menu.

99% of the time, autocomplete gives the best match for me, so inline
autocomplete would be useful 99% of the time. I definitely think this should be
a pref.
mpt: with the old auto-complete, it would almost always complete to something
short for me, like the front-page of a portal, not the full url of some page
deep inside the site. i guess the backend hasn't changed, so I'm curious as to
why it doesn't seem to do that now for me.
the old 4.x auto complete would first complete the domain for you.  but if you 
had only ever visited one page from within the entire domain it would go ahead 
and complete the entire URL for you.  

If you visited more than a couple pages from within a domain, it would 1) first 
give you the domain 2) and more, if you typed an additional backslash. As you 
continue typing deeper and deeper URLs it would do a new autocomplete after each 
backslash, each with the same exact behavior as the original. So typing a 
backslash would give you the best match up to the next backslash, so on and so 
forth for every backslash - UNLESS that was as deep as you ever got, in which 
case it would finish URL because it's was as deep as you had ever visited within 
the domain.

is this right?  

whether "smart" auto-complete works 90% of the time at guessing what i want is 
almost irrelevent to me, because instead i can rely 100% on a precise behavior 
which works the same way everytime - and now i can use it more like a tool.  once 
users discover the pattern, they can get reliable results that they expect. 

i like that alot better than super-human complicated algorithms which constantly 
second guess me. they might be correct 90% of the time, but that leaves 10% 
frustration and unreliability. 

Software should never do something that the user has not instructed it to do. If
you type in www.netscape.com/[enter] then you don't want to go to
www.netscape.com/news (or whatever).

From bug 51910:

I also have 2 other points in favor of not changing the text the user has typed:
1) IE doesn't does it this way. If we cannot have a better implementation that
IE, then we should act in the same way to avoid confusion when switching between
browsers.
2) The browser can never perfectly predict where you want to go, so you will
want to check any results that have been put into the url bar. A good way of
doing this is to use the arrows from the dropdown menu.

Assuming the user has two pages in their history:
http://www.netscape.com (no end slash)
http://www.netscape.com/sidebar

Then with the current method:
User types www.nets [enter] => User gets DNS error
User types www.nets [down][enter] => User goes to www.netscape.com
User types www.netscape.com/ [enter] => User goes to www.netscape.com. In the
current implementation, this would auto-complete to www.netscape.com/sidebar,
since that is the only item that matches in the history.
User types www.netscape.com/s [enter] => User gets 404 error.
User types www.netscape.com/s [down][enter] => User goes to www.netscape.com/sidebar

As you can see, it is one extra key press to get to the first predicted option,
instead of one extra key press (delete) to remove the autocompleted text when it
isn't wanted.

TouchTypists will notice it autocompleting and press delete before enter. If you
look at the keyboard when you type then this is not the case, and you will
assume you got to the page that you typed.

I have no objection to this being made a pref, but the default option should be
the current behaviour.
Thanks for speaking on our behalf, but I am a touch typists, and many of my 
friends that are trying to use mozilla right now are touch typists and are 
annoyed at not having the auto complete.

When you do as much typing as I do, you appreciate anything that saves you 
keystrokes and time. The down arrow key is a very far distance from where your 
hands are for touch typing and is an extra keystroke.

Plus, I can count at least five friends that have switched to Netscape because 
they didn't like the drop down auto complete, they liked Netscape 4.xx's auto 
complete.

Some one else mentioned that it was annoying that the whole URL get selected. I 
agree, I think only the part that is being auto completed for you should get 
selected.

I spend a lot of time just going to a select few URLs. In Netscape 4.xx I can 
just type in www.v and it will auto complete to www.voodooextreme.com. I hate 
having to reach over to the down key and back to enter or to the mouse instead 
of just to my enter key.

Not having proper auto complete right now is the only reason why I am not using 
Mozilla as my primary browser.

I could care less what the default preference is, but I think that both should 
be included and you should have the choice of one, the other, both, or none. Key 
word "choice", it's called good software design.

I would be inclined to suggest that having them both enabled by default would be 
the best, that way people who do not know to go to the preferences have both at 
their disposal and can pick which they wish to use.

I agree that software for the most part shouldn't intrude on user tasks, unless 
it's desired and expected.  There are careful visual cues however, which can 
offer meaningful and predictable suggestions in a way that isn't visually 
distracting - ways which do not involve lots of attention grabbing motion and 
extraneous flapping (peripheral noise) while the user is intently focused on a 
task that is crucial (i.e. task of typing in the URL).  

Personally, i find that an automatic drop-down window which is simultaneously 
mimicing everything i type, with lots of motion up and down, sort of disturbing.  
But that may be because i come from 4.x, and have not undergone the mind numbing 
experience of learning to live with IE.  However, if i were new to computers and 
the internet, i'd think the latter behavior would be alarming at first. 

I find that inline, history-based autocompletion of URLs, using careful and non-
disruptive visual cues, is easier to adapt to (albeit relatively less inclusive 
and probably less informative), and has the added advantage of being understood 
simply.  The real beauty of the 4.x method is that the chances that your URL will 
auto-complete incorrectly at the moment you hit enter, although still possible, 
are slim and easily recoverable - with every keystroke the variety of matches to 
your history diminishes.. So speaking in real terms, it is rare that users have 
to hit [delete] (or [spacebar]) to correct the autocomplete before hitting 
[enter], because the likelihood that the URL you intend to type just so happens 
to be the root of 1) another valid word(english or whatever) (and assuming that 
many common URLs start with valid words or prefixes); the chances are further 
obscured by of course the fact 2) that the valid word must have been in your 
history too.  And it is far more likely that the user is returning to a 
previously visited URL, than typing in the word prefix of a previously visited 
URL (but not totally impossible). Therfore, with the 4.x system there is high 
likelihood that auto-completion will result in one of two positive outcomes by 
time you're ready to push enter: 1) the desired URL which you had in history and 
was autocompleted for you; or, 2) your full URL typed without interruption.  The 
one realistic negative outcome is when the follow 2 requirements are both met: 1) 
a case where a user just so happened to need a prefix of a valid word or root 
(because most of the popular URLs use valid words or roots), AND 2) this valid 
word or root is a prefix of a URL which was already visited in history.  

Remember, there is of course the main motivation for autocomplete - people tend 
to frequently return to places they've been.  If you don't buy into that, try 
using a browser which doesn't have any autocomplete whatsoever for a while and 
see if you like it (try opera). 

So my point is that while 4.x isn't perfect it's pretty quiet, and it's 
dependable and predictable.  And, the negative outcome is reasonably and quickly 
corrected. In terms of choosing a default, this behavior far outweighs the impact 
of jarring motions and blurry sophistication of IE-style.  These characteristics 
should make 4.x-style inline autocomplete better candidate for default.  
Furthermore, i feel that we can improve 4.x visual cues by using faint or grayed 
text and/or bolding.  

For the prefs issue - in general i think we'd have a much safer user experience 
if we always believed in providing a basic tool, which empowers users to 
selectively add complexity at their own discretion, assuming that experienced 
users will have the notion to do so. In contrast to presenting the full power and 
sophistication of the browser by default; and just hope inexperienced users will 
subtract complex features until they can understand the interface.

If we can win a bunch of people over by stealing a characteristic IE feature 
which people have learned to use, then by all means we should, as long as it does 
so in a way which doesn't detract from the LCD situations. Therefore I'd vote to 
have a pref something like this for default:

[X] Inline autocompletion of URLs (default)
[ ] use Internet Explorer autocomplete behavior


To reiterate my points: inline autocomplete (with some more refined visual cues) 
is helpful (most of the time) and quickly recoverable (when it fails). And, it 
doesn't mimic every keystroke, jump up and down, cluttering the periphery with 
noise.



correction: 

"And it is far more likely that the user is returning to a 
previously visited URL, than typing in the word prefix of a previously visited 
URL (but not totally impossible)"

sorry, i didn't mean to say this sentence i was in between thoughts and got 
interrupted 

I found the old "automatic" autocomplete quite annoying, and I was happy to see
it "fixed" with the new dropdown autocomplete. Now that I followed Alex' pointer
to this bug from mozillazine, I am worried that the problem might come back.

To me, the main usability problem with the old "automatic" completion was that
it used to kick in exactly when I didn't want it. I typed something, pressed
enter, and then it suddently autocompleted to something I didn't want, and
loaded that.

Even if I notice the (wrong) autocomplete before pressing enter, it is annoying
that I have to look for ways to delete the unwanted part of the url.

I use autocomplete very rarely, if at all, but I don't like my software doing
things I didn't instruct it to do, and I find it especially bad if there is no
obvious way to prevent that from happening.

If you choose to have "automatic" autocompletion by default, then please include
a way to turn it off. A pref would be ok with me. Thank you.
*** Bug 86503 has been marked as a duplicate of this bug. ***
My $.02:

I think the situation will be a lot better when the dropdown is properly sorted 
(and I think that should have been done before checking in...).  However, it 
gets annoying having to reach for the down arrow whenever you want to 
autocomplete (but inline autocompletion also gets annoying :-/). I generally 
dislike prefing things as a solution, but I think this is important and broad 
enough to justify it.  However, I didn't see much negative pr1 feedback about 
the autocomplete behavior.

Of course, an ideal solution would be some type of usability study, but 
conducting one of those would just be silly, right?

From <http://mozilla.org/projects/ui/communicator/browser/search/>:

"Status: Implementable Proposal. Usability testing has to be successful before 
ship."

Who are we kidding?  I think it's time we stop putting that at the top of specs.
*** Bug 87636 has been marked as a duplicate of this bug. ***
> There are careful visual cues however, which can offer meaningful and
> predictable suggestions

No matter how wonderful the cue is, it's still useless if it only appears for a 
small fraction of a second between the time an unwanted auto-completion appears 
and the time you unwittingly hit Enter.

>                         in a way that isn't visually distracting - ways which
> do not involve lots of attention grabbing motion and extraneous flapping
> (peripheral noise)

It's no more `peripheral' than the menu which pops down when you click on a 
menu title in the menu bar. As for attention grabbing-ness, there are several 
visual bugs currently with the auto-complete menu, and *none* of them would 
magically go away if you added inline auto-completion as well.

> [ ] use Internet Explorer autocomplete behavior

Ok, you lost me. Why should I have to install Internet Explorer, just so I can 
see how a particular thing behaves in that browser in order to make a decision 
which Mozilla's UI people didn't feel competent enough to make themselves?
>It's no more `peripheral' than the menu which pops down when you click on a 
>menu title in the menu bar.


- clicking on a menu title results in an expected outcome. 

- there's an innate difference between the task of typing 50 characters of text 
in a field, and clicking on something.


>Ok, you lost me. Why should I have to install Internet Explorer, just so I can 
>see how a particular thing behaves in that browser in order to make a decision 
>which Mozilla's UI people didn't feel competent enough to make themselves? 

- bear with me here, it's a signature IE feature.  they claim to have 80 percent 
of the market, I think they've established themeselves. even so, the wording of 
the actual label doesn't concern me as much as the interaction, because i am not 
a writer.  

I also did not like the old autocompletion because the URL would be
autocompleted with a URL that I did not want *right before* I pressed ENTER!

However, it would have been OK if the autocompletion was either:
   1) Triggerred by a keystroke (ie. pressing TAB) or 
   2) Hilited the added text BUT required an extra keystroke (other than ENTER)
to accept it.

For example, I would type:
www.deb<TAB>Bu<TAB><ENTER>
to get to "www.debian.org/Bugs/"

Elaborating on #2, the selection could be "accepted" by hitting the <RIGHT
ARROW> or <END> keys, for example, causing the autocompleted text to loose its
special hiliting. However, this form of automatic completion may be more
confusing than using <TAB> (or other key) as the hilited text would NOT be
accepted if the user simply pressed <ENTER>.

Also of note, perhaps autocompletion could work at one path component at a time.
This would mimic the shell's autocompletion, stopping at each directory level.

For example: If there is only one directory named "bar" under /home/foo, then
entering /home/f<tab> returns /home/foo/ and entering /home/f<tab><tab> returns
/home/foo/bar/, etc.

------------------------------------------------------
FYI, Other bugs related to this discussion:
Ordering of autocompletion choices -- Bug 72870.
Autocompletion not matching entire string -- Bug 87667.

Keep in mind, that the tab key switches focus to the next form element.  So you 
can't really do the shell style autocomplete unless you are willing to break 
focus/navigation

I never use Tab to leave the url bar, so I would be willing to break that
functionality (for me). There seem to be more bugs where people agree to
disagree on how the tab key should behave (e.g. bug 29086), so maybe this
warrants a pref.
With the future pref that has been mentioned, how about a timer option is added
to give people like me the old option back (which was much better IMO), and
alleviate problems experienced by people like donr.
ie. pref to set the timeout before autocompleting the URL.
Keywords: nsbeta1
About delays:

An adjustable delay would help avoid unwanted autocompletions. The longer the
delay, the less likely the user will get an unwanted autocompletion, but it also
makes autocompletion less useful (slower).Therefore, the delay should be kept
small, but unwanted autocompletions should be avoided by another means.


As per my second suggestion (see previous comment):

Autocompletion would require the user to confirm the autocompleted text in some
manner (ie. pressing the <Right Arrow> key to move the cursor past the hilited
portion of the URL). I acknowledge that there may be some users who expected the
old behavior (to just press <Enter> to accept the autocompleted URL). So, to
reduce confusion, we could also mark the text specially (ie. italicize the
autocompleted part) to let the user know that it is not part of the actual URL
yet. This could be the better solution for users that do not know about TAB (or
TAB-like) completion, or those who would be confused about the multiple purposes
of <Tab>.

On the other hand:
The key to trigger autocompletion could be <Right Arrow> or <Ctrl><Right Arrow>
instead of <Tab>.

--- Correction of Bug # ---
Ordering of autocompletion choices -- Bug 78270.  (not 72870)


Attaching a patch that fixes the autocomplete XBL (in 
xpfe/components/autocomplete) to behave like IE's autocomplete and some test 
XUL. I don't know if Mozilla's urlbar uses the autocomplete binding but 
Komodo's find and replace dialog does now. Hopefully this will be useful for 
discussion. This is how I think Mozilla should behave, as I think was echoed by 
Hyatt.

The autocomplete binding now behaves as follows:
- There are two distinct autocomplete textbox behaviour in IE.
  "urlbar": use the <Tab> character to cycle through the list 
            of matches to the current string
  "in-line entry widget": do *not* use the <Tab> for autocomplete,
           hitting <Tab> terminates autocomplete and the event is
           bubbled up so it can cause the focus to be switched
           to the next widget in the tab order
  This patch offers the "useTabComplete" option to select which you
  want. Default is useTabComplete=true, i.e. "urlbar" behaviour
  because this was the previous behaviour. BTW, I think the default
  should be false.
      <textbox type="autocomplete" useTabComplete="true"/>
- Hitting <Return> finishes autocomplete and closes the results popup.
- Hitting <{Down|Up}Arrow>,<Pg{Down|Up}> will synchronously build
  the results list and open the popup.

Trent

if we can get a better sorting method for the urls, i'm fine with it not auto-
completing. i've grown accustomed to the current behavior and i find that it's 
alright by me.

get me off of this infernal bug.

*** Bug 88409 has been marked as a duplicate of this bug. ***
Marking mostfreq at 10 dups.
Keywords: mostfreq
With the autocomplete behavior like in Netscape, I constantly found myself typing:

www.moz<RIGHT><RIGHT><RIGHT><RIGHT><RIGHT><RIGHT><RIGHT><RIGHT><RIGHT><SHIFT+END><DEL><ENTER>

But with the current drop-down autocomplete behavior in mozilla, I regularly type:

www.moz<DOWN><ENTER>
Well in Netscape I would do:
www.moz(wait a split-sec for autocomplete)<ENTER>

which is better than (when used to Netscape):
www.moz(wait a split-sec and see dropdown with selection you want)<ENTER>
(crap, www.moz not found)<DBL-CLICK><BKSP>www.moz<DOWN><ENTER>
To add my opinion:
a) I dislike any autocomleption that enters text that may be submitted when not asked for. I was wery annoyed by browsers that completed URL as I was typing and when I hit enter I was brought to a page I did not want.
I expect that some people may want this but many will not.
-> make "autocompletion on demand" - text is completed only when some special key is pressed ( tab or right arrow or whatever - why can't be the key bindings configurable)
make optional (means it may be turned on in prefs) automagic completion
make an optional hint for autocompletion on demand - some grayed text or something that shows what would be completed
b) Another problem of autocompletion is sorting (this occurs in Mozilla's dropdown as well). Sorting is done alphabetically which makes it difficult to get autocomleted something different from the first match.
ie all bugzilla.abisource.com* get before bugzilla.mozilla.org* (and there are quite a few of them)
This can be well tested when matching URLS from whole browsing history when autocompleting in URL bar. This idea is good (as long as a better sorting algorithm is developed) but some users may prefer to match only URLs they typed or URLs they typed and were succesfully loaded so there should be a pref (c).
I think that sorting should be done in a way that allows quickly select any URL from a long list. What about this one:
 1) find first char where two URLs in history differ
 2) divide history into groups of URLs which are the same up to this char
 3) from each group select a representative based on alphabetical order /mostfreq/lastvisited
 4) sort these in order based on alphabet/mostfreq/lastvis(possibly different sorting from the one that yielded the representative)
 5) make this your cycle list / place this in the beginning of pulldown
 6) if you need more items to fill the visible part of the menu, add subgroups below groups or take more than one character to differentiate groups
d) Last problem is that you usually cant guess the correct URL from the first few letters
-> "part completion" completes up to first dot/slash and can't make too bad mistakes
"to diff completion" completes up all letters that don't differ and lets you coose the next important letter

I think that best solution for unexperienced user is on-request part & to-diff completion with some indication of to-be-completed part which is transparent and unintrusive. Stopping on anything important gives great control over completed text at the cost of some additional keystrokes.
Don't think I care this much... removing my cc.
I am fine with the current implementation, although I do miss the old and agree
with a threeway pref, for IE style, IE and text inputted, and NS 4.x style.  My
only problem thus far with the current implementation is the nonsensical way it
chooses to choose which domain to go to.  For example I type www.p  and get
personals.yahoo.com(I enjoy a good laugh) instead of www.penny-arcade.com which
I visit far more frequently and actually has a www in front of it.  I'm thinking
if the url selection was less retarded, I wouldn't really miss the old style at
all.  At least the old style didn't replace www.p with personals  and actually
completed what you typed.
How about if the user presses 'delete' when autocomplete completes the URL for him, Moz will not try to autocomplete the URL anymore until he erases all the text in the location bar and types a new address, or visits a new page?

Can we just have the aforementioned pref for the 3 types of autocomplete behaviour?
Adding my vote to enable the old behavior, at least via a pref.
Adding my vote for the following behavior:

Non-greedy inline autocomplete with dropdown that works as dropdown currently
works (it's good, but I miss autocomplete, too).  In other words, starting with
the first letter after www. (or after the protocol if the host name is not www),
match the most commonly visited host that starts with that letter, with a right
arrow needed to finish the complete, or a down arrow into the dropdown box. 
Then, the first letter of the top-level directory name triggers an autocomplete
of the directory name, etc.

Does that make sense?

Thanks.
I have just landed a bunch of prefs that will allow you to customize the
autocomplete behavior as you please.

Open prefs and go to Navigator > Smart Browsing.  Click the "Advanced" button. 
Customize and rejoice.

This bug is now moot. Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Sorry for the spam, but I noticed that an issue in this discussion was that a
lot of users miss one-key autocomplete entry without having to move your hands,
and hitting TAB was the solution to that.  Well, bug 86643 has been filed to get
rid of TABing to autocomplete.  I don't know if this was made an option in
hewitt's patch, but if not, please go over to that bug and tell them that you
like tabbing to autocomplete (if you do, that is).
How about a pref for autocomplete one step at a time?

As in, first the website, then the first directory, then the next directory, then the file.

Eg (where stuff in parantheses is the autocompleted stuff):

http://www.m(ozilla.org/)
then,
http://www.mozilla.org/q(uality/)then,
http://www.mozilla.org/quality/h(elp/)
When talking about component autocomplete: components should be delimited by dots as well because  bugzilla.abisource.com and bugzilla.mozilla.org are too log and too similar to be autocomleted at once.
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: