109758 - Make location bar autocomplete expand to partial URLs (history tab completion)

Status: RESOLVED DUPLICATE of bug 382187

(SeaMonkey :: Autocomplete, enhancement)

Description

[Michael Cramer]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5+) Gecko/20011109
BuildID:    2001110906

When hitting "tab" in the location bar after entering a partial URL, the filled
in URL should be the longest URL-substring of all matching URLs in the location
history. 

Reproducible: Always
Steps to Reproduce:
1. Type something like "ww" into the location bar.
2. Hit tab.

Actual Results:  Assuming you have several URLs that start with "ww" in your
history, step 1) will start listing them, as it should. 2) will then fill in the
location bar with the first url in the list.

Desired Results:  2) should fill out to the largest prefix matching your
history. Something like "www.y", if the only things in your history are
"www.yahoo.com" and "www.yellow.com". 

Filling in the first URL from the history when you hit tab seems less than
useful. If I wanted the first URL I would hit down-arrow and enter. Having the
auto-complete work more like a tab-completing Unix shell would be far more
useful. Something like this would be possible (depending on your history,
obviously):

w<tab>.moz<tab>bui<tab> could easily get me to
"http://www.mozilla.org/build/unix.html" even if I have NEVER visited
"http://www.mozilla.org/" but instead always go directly to sub-areas through
bookmarks.

Comment 1

[Boris Zbarsky [:bzbarsky]]

except tab leaves the location bar so as to allow keyboard navigation of the UI,
no?

Comment 2

[Michael Cramer]

No...in this case, the tab just selects the first thing from the drop down.
Focus remains on the location bar. Tab in this situation is the same as
down-arrow. Repeated tabs just cycle through the drop down.

Comment 3

[Jesse Ruderman]

> Repeated tabs just cycle through the drop down.

That's one of the most annoying bugs in IE and Mozilla (at least for me).

Comment 4

[sairuh (rarely reading bugmail)]

autocomplete.

Comment 5

[Michael Möllney]

Although I like the tab - autocompletion scheme of UNIX shells I'd like to
behave the autocompletion of the URL Bar in a different way.

Proposal:
---------
I'd like to have the completion sorted by last visited, not alphabetically.


When I type in an URL that I didn't bookmark before I'd like to have presented
the URLs that might be a completion in it's TIMELY sorting not in an
ALPHABETICAL order.

For me it's most probably that I want to return to a page I use often but just
didn't bookmark and these are sites that I recently visited.

Let me give you an example:

I want to visit the german site of google: www.google.de. However the google.com
site was also visited on two different occasions.

Using the completion panel I have to type:
www.goo + cursor down 3 times + enter
(overstep two google.com sites)

Every time I have to do this again, until www.google.com leaves the Site-History.

If the list would be presented in a reveres timly manner the last visited would
be presented first and I could use it as a reminder, what place I'd like to visit.

Let's expand my example: I also have some www.geocities.xxxx and www.gmg.xxxx in
the panel so when typing until www.g I even don't see the google I visited last
time.

Summary:
--------
When typing in an adresse auocompletion should react not alphabetically like in
an public telephone book (most of the sites arn't worth it to be revisited) but
should show me sites, that are probably the ones I'm looking for. The only ones
netscape could guess about are that I just visited.
Just finer would be a completion showing me the sites I even don't know about
but solves my question, but I guess this mindreading will not be implemented
until Mozilla 1.0 !-)

Comment 6

[Asa Dotzler [:asa]]

bug 109006?

Comment 7

[Michael Cramer]

No...this is more fundamental. The original request was for "tab" to not cycle
through the list of URLs, but instead act like it does in a modern Unix shell --
filling in the location bar with the longest substring of all the listed,
matching urls. So if your location history contains:

http://bugzilla.mozilla.org/show_bug.cgi?id=109758
http://bugzilla.mozilla.org/show_bug.cgi?id=23456
http://bugzilla.mozilla.org/show_bug.cgi?id=109888

And you type "bugz", those three would show up in the drop-down. Hitting tab
would then change the location bar to:

http://bugzilla.mozilla.org/show_bug.cgi?id=

(because that's the longest substring). At which point you could type a "1",
which would eliminate bug "23456" from the list. Hitting tab again would give you:

http://bugzilla.mozilla.org/show_bug.cgi?id=109

Etc...

Comment 8

[Vadim Berezniker]

i've thought of this before as well. glad to come across this bug number.

those of you have used bash(or other) tab-completition know how time saving it
can be.

Comment 9

[Ronny Adsetts]

This enhancement should be all platforms/os's.

Comment 10

[Jeremy M. Dolan]

I second jruderman in comment 3. Whatever the fix, please consider the need to
get focus back to the content area easily. Bindings like ctrl-w to get rid of
the tab don't work from the URL bar, and it's very frustrating having to tab
through 5 objects just so ctrl-w will work.

I suggest a binding other then tab to do the "tab" completion. One press of tab
anywhere in the history dropdown or url bar really should focus the document body.

Comment 11

[Jo Hermans]

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

Comment 12

[Zack Weinberg (:zwol)]

Bug 137574 contains a precise description of how I want to see this feature
implemented.  Please read it.  I will repeat the two most important details here:

1) NO COMPLETION HAPPENS until I push Tab.  No drop down, no text fill in, NOTHING.

2) Do NOT blindly fill in the longest common prefix of all completion
candidates.  Stop at the next URL separator (/, ?, &, =, etc).

Also, Tab is the only acceptable choice for keybinding.  All other programs that
implement autocompletion trigger it with Tab.

Comment 13

[rupert smith]

i second the desire for autocompletion to stop at URL seperators; one very
common operation i want to do is autocomplete solely the domain, and then type
in the rest of the URL. 
generally i have to autocomplete, the delete a load of text, then type. this is
often slower than just typing the thing out :(

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[resigned]

re: use of tab instead of some other key (comments 7,10,12,13):

This is obviously begging to be a "user-configurable" option. When there are
clearly such good, but sadly contradictory, personal preference reasons for
using tab as the key, it should be up to individuals to decide how they want it, no?

Personally, I agree with both camps. Due to several other very long outstanding
bugs (e.g. "autocomplete dropdown appears even when there are no matches",
combined with "browse-tabs cannot be navigated using ctrl-pgdn etc when focus is
on address bar") I have real problems with "tab to get to body of browser" not
working at all in several situations.

Equally, I repeatedly try to use tab to autocomplete as requested by the
original poster of this bug, as a natural expectation arising from using bash
every day of my life.

Comment 16

[Konstantin Vainer]

the behavior i think would fit both "camps" :

1) the auto-completion of address-bar is on constantly (no need to hit any button)
2) the autocomplete "expands" only to closest separator -  . / ? =
3) there is a selection of the completed text,
   but only the LAST completed portion is selected
4) the history-bar opens on autocomplete (if there is any matching address);
5) the addresses in history-bar are shown on time-basis (lifo) AND the number of
times visited
6) whenever tab is pressed - it changes focus to the document area

Comment 17

[Zack Weinberg (:zwol)]

No, this does not fit the camp I'm in.  Your points 2-5 are fine by me, but 1
and 6 are unacceptable.

NO COMPLETION WHATSOEVER HAPPENS UNTIL I PUSH TAB.  And it has to be TAB.

Comment 18

[Zack Weinberg (:zwol)]

Let me expand a bit on the previous comment.

"It has to be TAB" -- that's just a matter of what my fingers are wired to
expect.  It occurs to me that both camps could be satisfied on this issue with a
DWIM heuristic: if something else was just typed in the location bar, then
complete, otherwise cycle input focus.  Also, a general keyboard-shortcut editor
would make me happy.

"No completion whatsoever happens until I push TAB" -- this is somewhat less
obvious.  The primary reason for it is that, because autocompletion fires as
soon as a single letter is typed, it reliably fills in the wrong URL.  And
because it fills in the entire wrong URL (if it thinks it has a single match) it
is difficult to correct.  I have frequently typed a few letters, seen it fill in
the wrong URL, hit delete to get rid of the selection, typed another letter,
seen it fill in the *same* wrong URL, repeat to frustration.  The other changes
to completion, discussed in this bug, would mitigate this problem, but I think
it would still be a problem: so I want completion to happen only when I
explicitly ask for it.

A secondary reason is, at the time I filed bug 137574, autocompletion was SLOW:
it made the URL bar consistently lag up to ten keystrokes behind what I was
typing.  This seems to have been improved since, although that might just be
because I now use Galeon as primary browser, so the Mozilla profile doesn't have
a huge location history to search through.

Comment 19

[rupert smith]

"I have frequently typed a few letters, seen it fill in
the wrong URL, hit delete to get rid of the selection, typed another letter,
seen it fill in the *same* wrong URL, repeat to frustration."

ahh, but if the completed portion were to be selected, then you wouldn't need to
delete as the next character of your URL your overwrite the selected, completed
text.

the only diversion comes if your desired URL is a substring of something in your
history, in which case you'd have an extra keystroke before hitting return.. not
ideal, but liveable. but again, that should be mitigated somewhat by
autocompleteing only up to the next seperator.

in the end, no solution is going to please everyone. and as there appears to be
a desire for preference non-proliferation, i think konstantin's proposal is a
viable compromise, even though it's not precisely what i would choose.

Comment 20

[Zack Weinberg (:zwol)]

<blockquote>
ahh, but if the completed portion were to be selected, then you wouldn't need to
delete as the next character of your URL your overwrite the selected, completed
text.
</blockquote>

But that's not what should happen!  After partial completion, I want no
selection and the caret at the end of the line, so I can <i>keep typing</i>. 
Tell me this isn't the normal case.

I sympathize with the desire to avoid preference proliferation.  But I don't
think the posters in this thread are taking into account the degree to which
people's fingers are wired to expect specific, consistent behavior from
keystroke commands.  And in the case of completion, the wiring comes from Unix
shells, which behave in the fashion I described in bug 137574.  URL bar
completion is <i>worse than useless</i> for me unless it implements exactly that
algorithm.

Of course, other people's fingers may be wired differently.  Hence preferences.

Comment 21

[Konstantin Vainer]

you are not completely right...
and yes i did not write anything about the location of carret after such
completion...
i was not sure what would be best - but you are probaby right and having it at
the end would be good idea;

but selection would be there mostly for a case when autocompletion did not get
you what you wanted - and then simply hitting backspace/delete you would "undo"
the last completion part...

so i think together with what i proposed before it would be ok - especially due
to the fact it is still avoiding inconsistency in _browser_ behavior - and that
is much more important in the case than consistency with the shell ... 

Comment 22

[Konstantin Vainer]

and another thing...
as a variation for "autocomplete always on" .. 
the autocomplete can be "triggered" also by an interval of time that person is
not typing... lets say about 100 or 200 miliseconds...

then, lets say you are typing "www.moz", (thats pretty fast - by now the
autocomplete did nothing) and then you take your hands off the keyboard for a
while and look at the screen - what you see _almost_ immediately is "www.mozilla."

this way the autocomplete does not "bother" you typing (not consuming rsources
while you type) and yet does the job in a flash...

Comment 23

[Zack Weinberg (:zwol)]

I think you misunderstood about the caret position.  If completion leaves the
text it inserted selected, then it doesn't matter where the caret is; the next
key I hit will obliterate the insertion, which is not what I want.  I want to be
able to type "ht<TAB>w<TAB>sl<TAB><RET>" without pausing for breath and wind up
with "http://www.slashdot.org/" filled in and loaded.

Consistency in browser behavior - I assume you mean cross platforms; that takes
a distant second to consistency between the browser and all the other tools I
use all day.  I use only one platform, but I switch between the browser, the
shell prompt, and Emacs hundreds of times a day.

Completion on a .1sec pause - I'd have to use it to know if it was any good or
not.  However, my gut feeling is that I can insert a TAB in the middle of a
keystroke sequence a lot faster than I can insert a .1sec pause there.  

Comment 24

[Konstantin Vainer]

True...

Then probably it can be :
a) autocomplete works BOTH on timeout and on TAB (but tab - only if user typed
at least one char since last completion or from the beginning of the line)
b) configurable between these two...

What would you say about that ?

Comment 25

[Craig Rae]

Would it be possible to either clone this bug or take this and one of the other
many bugs and separate them so that the following are worked on independently:

1. Improved autocomplete that doesn't just grab the first matching item in the
history list.
2. Autocomplete triggering (timeout, tab, whatever).

The way I see it, you generally have two requests about autocomplete. The first
is to change the autocomplete to match something a bit more useful. I personally
dislike the way Moz currently does autocomplete - if I want to go to the forums
at ars, I'm sick of typing "arstechnica.infopop.net" to try to go to the forum
list page only to invariably have
"arstechnica.infopop.net/OpenTopic/page?091374toijehrg9p143yyt" or whatever from
a past topic be autocompleted as the entire URL.

The second is how to trigger autocomplete, whether it be from a timeout, a
keypress, an errant x-ray striking a memory cell, whatever.

The reason I ask is that I know I personally don't care about how autocomplete
is triggered, but I do know that I care about *what* gets autocompleted. In my
mind, what currently happens is just wrong, and looking at the maze of
duplicated bugs, I'm not the only one that thinks this way.

Hell, this bug was entered in 2001, and Moz's current behaviour (1.2.1, 1.3a)
doesn't appear to be much different from back then. Can we please have some
final ruling about how autocomplete is going to work and put this whole
autocomplete thing to bed?

Comment 26

[Aaron Kaluszka]

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

Comment 27

[Jamie Zawinski]

I guess this bug is never going to actually be fixed, but bug 212907 is relevant
as well, in that if TAB completion were implemented properly, it would fix both
bugs.

Comment 28

[Tony Mechelynck [:tonymec]]

No comment in more than four years. Nothing much significant ever.

Location bar autocomplete has recently undergone a complete overhaul in Firefox. I expect the corresponding backend to be ported to Sm-trunk but I have no idea when.

Comment 29

[Mårten Svantesson]

For Firefox I finally hacked together an extension with essentially the functionality requested in this bug. It probably works in SM with only small changes. Since I don't use SM I probably won't make those changes myself.

URL Tab Completion
https://addons.mozilla.org/en-US/firefox/addon/6257

Comment 30

[Robert Kaiser]

It's not done with tab completion but what the places-based smart location bar does is very similar to what's requested here, so duping to the bug that introduced places history.