Closed Bug 175725 Opened 22 years ago Closed 21 years ago

url auto-completion logic is incomprehensible

Categories

(SeaMonkey :: Location Bar, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 109758

People

(Reporter: jwz, Assigned: hewitt)

Details

After having used it for many months now, I still can't tell *what* order or
priority you're giving to autocompletion in the URL typein field.  It just
doesn't make any sense at all.  Do you present possibilities in hash order, or what?

Here's how it out to work, in any kind of sane world:

  - typing some text offers you a completion menu of all known URLs that begin
    with exactly that text.
  - hitting TAB completes to the next delimiter or ambiguity. 
    - delimiter is "/"
    - ambiguity is the point at which you have passed the common prefix
      of all the current matches.

For example, if the following URLs are known:

   http://www.jwz.org/
   http://www.jwz.org/webcollage/
   http://www.jwz.org/webcollage/explain.html
   http://www.jwz.org/webcollage/collage.html
   http://www.jwz.org/webcollage/webcollage
   http://www.jwz.org/why-cooperation-with-rms-is-impossible.mp3

Here's how it should go:

   I type:    http://www.jwz. <TAB>
   I get:     http://www.jwz.org/
   I type:    http://www.jwz.org/ <TAB>
   I get:     http://www.jwz.org/w
   I type:    http://www.jwz.org/we <TAB>
   I get:     http://www.jwz.org/webcollage/
   I type:    http://www.jwz.org/webcollage/e <TAB>
   I get:     http://www.jwz.org/webcollage/explain.html

I think that any behavior other than that is complete lunacy.

As I said, I can't even figure out what you're *trying* to do, but I know that
it never, ever does what I expect.  Is it documented anywhere?

Also, I think that characters are processed out of order: if I type fast, I get
different completions.  That is, if I type "a b c d TAB" slowly, I get different
results than if I type it quickly -- if I type quickly, I get the results I
would get if I typed "a b TAB", as if TAB is being treated as an interrupt
character instead of being processed in the queue with the other input
characters, and the typein characters and TAB character are being handled by
different threads or something.


Red Hat Linux 7.3, Mozilla 1.2b.
Despite the fact that I use tab-completion in other applications all the time,
I've been ignoring Mozilla's auto-complete feature for months because of this
bug.  

"Hm, when I push tab, it does something dumb.  I won't push tab."
Um... tab in most GUI applications on all the platforms we run on switches focus
around. So it's not acceptable as a completion character.

Here's the way autocomplete now works.  We present all results that start with
the string you have typed, modulo www. or ftp. for ftp:// urls (so typing "foo"
will match http://www.foo), sorted in reverse order of number of times visited
in the near past (so pages you visit often are near the top).

There _is_ an RFE already for having some key to complete to the common prefix
of all matching urls; I can't find the exact bug number right now.
Whiteboard: DUPEME
Uh... you said "we can't use tab" and yet when I hit tab, it completes,
it just does so stupidly.  Huh?

> sorted in reverse order of number of times visited in the near past

Never in a million years would I have guessed that that's what it's doing.
The behavior is completely non-obvious.

Everyone in the world expects TAB to complete.  If you have focus issues related
to TAB, find another way to resolve them (e.g., use shift-TAB to focus out of
the current widget.)  

(I also find it infuriating that I can't type a literal TAB character into a
textarea, but have to type it somewhere else and paste it.  This is a more
general problem.)

I would also find it sensible for Space to complete to the common substring, if
you won't use TAB.

Though, in Emacs, TAB complete to the common substring, and SPC completes to the
common substring, or up to the next word delimiter, whichever is shorter.  So if
the common substring was "www.jwz.org/webco" then hitting SPC in succession
would give you "www." "jwz." "org/" "webco".

In fact, TAB is not currently being used for navigation in the URL bar!
I type the characters

     w w w . j w z TAB x

and what is in the URL field is now

    http://www.jwz.org/webcollage/collage.htmlx

with a blinking I-beam at the end.  So "we can't make TAB be sensible because
it's used for navigation" doesn't hold water, because it's not being used for
navigation, it's being used for completion.


Internet Explorer, Windows Explorer, the Gnome file dialog, and Mozilla all use
tab as the URL completion character.  It works really well.

---

Dup of bug 142190 and/or bug 164945?  They all look roughly the same.
OK.. could we have either fixed behavior (a la jwz's description), or a
preference called borwser.urlbar.autoAmbush that selects whether to use
"shortest match" or "happens to be the LRU entry" semantics for auto-complete?

I mean - does *ANYTHING* that supports autocompletion behave this way?  If I'm
on a Unix box, and I enter "/usr/in" and ask for completion, I get
"/usr/include". I most certainly don't get
"/usr/include/c++/3.2.1/i386-redhat-linux/bits/codecvt_specializations.h" just
because the *last* time I hit escape I was *IN* the 'bits' directory looking at
a specific issue.
Dupe of bug 109758?
I use it set up with "auto compelete best match as you type", "show list of
matching results" and "match only websites previously typed".

The problem in that if I want to go to a particular url, after having gone to
some other urls at the same site, it keeps poping up the list, in the same wrong
order, over and over.  So I find myself typing "f", and picking the 3rd item on
the list, over and over.  Obviously, this 3rd item should be moved up.  And
clicking in the location bar should be considered "typing".

Not even pasting a URL into the location bar seems to be considered "typing"!

But you get tons of extra junk without the "match only websites previously
typed" preference checked.

the idea is not to present some well understood algorithm to the user. the idea
is to show the most likely site they are going to visit. If I have visited
www.aaamotors.com 100 times and visited www.aaaardvarks.com once, I'm most
likely going to visit aaamotors.com even if aaaardvarks comes first alphabetically.

We use other things to weigh the priority of what shows up first such as:
- if the user has actually typed the URL in the URL bar before (as opposed to
visiting it using a link)
- if there is a toplevel site first...

If you may find this completely incomprehensible, but people hated it when we
simply sorted matching urls alphabetically - it meant that ALL sites that began
with www.canada.com beat out all sites that began with www.cannedham.com even
though 99% of the visited urls on www.canada.com might be completely
incomprehensible. 

Sure, SOME web sites use "/" as a non-obvious delimiter, but my mom doesn't know
what a delimiter is, and doesn't want to see
http://www.canada.com/f01@#05,,,,f9134.jsp or somesuch completely insane url.


In other words, "The Principle of Least Astonishment means nothing to me."

Thank you for clarifying your ridiculous position.
The principle of not being an ass has come into play here as well, so that may
actually be the source of your confusion.
So here's another example of why the current behavior is terrible:
I want to type in the URL "http://www.livejournal.com/invite/"

I type "www.li"

The popup menu comes up, showing literally hundreds of completions.  
In *non-alphabetical order*, so finding the completion I want is impossible.  

The fact that it even bothers to pop up that menu, with a scrollbar  and
hundreds of non-ordered entries, is worthless: all it does is slow down the
interactivity of the program, since apparently generating that list takes it
more than a second.  There's no chance I'll be able to find the item I want in
that list.  If it were ordered, it might have been useful -- it would have at
least been *possible* to find the URL I wanted, though it still would have been
time-consuming, since there were way too many items to scroll through.  Even if
they were ordered, it would have taken less time to type in the full URL than to
find it in the list.

So now I have to type out "www.livejournal.com/inv".
Oh, there it is!  Now I can click on it.

The auto-completer saved me exactly 3 characters of a 26 character URL, plus I
was typing "blind" for two seconds, waiting for Mozilla to catch up (since it
doesn't echo my characters while it's off in la-la land generating the
completion menu.)

If it was working sanely, then I would have been able to type

  w TAB li TAB inv TAB RET

10 characters, with feedback all along the way.  It would have been most triumphant.

The current behavior is most non-triumphant.


It is baffling to me that anyone finds the current behavior anything less than a
total impediment.  Does anyone find that it ever does what they want?  Really? 
Do you just like, only ever visit the same 5 URLs or what?

I never find the current state of autocompletion helpful at all.  I almost
always end up having to type the URL out, unless I happen to see what I want in
the list.  I participate on a few web boards.  Often I will go to type the URL
of one and the first few results are actually compositions of postings I have
made, not the root of the site or some subdirectory thereof.  Those are
completely useless to me.  The way I see autocompletion working is completing up
to the root of the site as you are typing it, then completing to the next
subdirectory as you are typing that, etc.  Does that make sense?  Certainly how
I said that I get results does not.
It's worth pointing out that mozilla's URL completion, in true Open Source
style, is a duplicate of MSIE's functionality.  I don't know anyone who uses it,
even in MSIE.  Well, my girlfriend uses it, but only when it does something that
approximates the behavior jwz is suggesting -- she types "www.go" and uses it to
complete out to "www.google.com", but that's about it.
The functionality Alec was talking about would in fact be ridiculous.  There's
no reason to give the user an alphabetically sorted list of all of the URLs that
start with the text they've entered so far, for reasons that Alec and jwz both
mention: it's going to be a huge list, and it's going to have very little to do
with what the user might want.

So, if you're going to bother providing the list, that's obviously not the way
to do it.  And the current method sucks a lot, too.  Here's a decent way to do
it:

I type "www.li".
I get a list of all of the URLs I've been to recently which start with "www.li",
*truncated at the next delimiter*: "www.livejournal.com", "www.liquor.com",
"www.liver.com".  These could be sorted alphabetically, or by how often or how
recently I've been to the site.  I don't really care, because the list will
already be much more useful.

I press <TAB>, and get the first entry in the list "www.livejournal.com".
I continue typing the URL, out to "www.livejournal.com/u".
I get a list of all of the URLs which start with that string, truncated at the
next delimiter: "www.livejournal.com/users", "www.livejournal.com/uganda".

And so on.

Alec said: "the idea is not to present some well understood algorithm to the
user. the idea is to show the most likely site they are going to visit."

If I'm *typing in the location bar*, how likely is it that I'm trying to visit
"www.livejournal.com/talkpost.bml?journal=nosuchjournal&itemid=1234567"?  Isn't
it much more likely that I'm thinking I'll type "www.livejournal.com"?  And if I
*were* looking for a ridiculously long URL I'd typed in the past, I wouldn't be
able to find it in the current scheme, unless it happened to be the one I'd been
to most often, or something like that.  With delimiter based completion, I could
get it rapidly if I really wanted it.

*** This bug has been marked as a duplicate of 109758 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Product: Core → SeaMonkey
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.