Closed Bug 175725 Opened 22 years ago Closed 22 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: 22 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.