40643 - Location bar autocomplete ignores my input and does wrong thing

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P2)

Description

[selmer (gone)]

I have a couple of keyword bookmarks so I can type in URLs like "bug 12345" or
"who selmer".  After using "who selmer", I attempt to use "bug 12345" but
autocomplete turns it into "bug 12345 [>> who selmer]" and if I hit return it
does "who selmer" instead of "bug 12345" or even "bug 12345 >> who selmer".

This is slightly annoying since now I have to type return really quickly after
the last meaningful character in order to use these URLs. (This defeats the
autocomplete timeout and causes my input to be recongnized.)

Why is this completely unrelated item attempting to autocomplete in this case???

Comment 1

[selmer (gone)]

This is using build 2000-05-25-08 on NT.

Comment 2

[Sean Richardson]

I've seen the same problem several times after selecting the existing
URL and pasting in a new one -- the URL bar ends up showing "new >> existing"
with everything after the new URL selected -- in builds from the last few
days on WinNT, including 2000-05-25-08-M16, but reliable steps to reproduce
are eluding me. 

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

IMHO the ">>" autocomplete should be completly removed. I don't really 
understand how it is supposed to work but it seems to me that it is totally 
unneccesary when the "popup-autocomplete" works and just annoying until then

Comment 5

[Doron Rosenberg (IBM)]

Upping severity, this is very annoying. ALso, it seems that if I copy a url,
paste it into the urlbar, and this bug happens, paste will now paste the text
oafter the >>

Comment 6

[Doron Rosenberg (IBM)]

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

Comment 7

[Claudius Gayle]

I looked at this a little bit and I get the sense that the code gets confused when it's first initialized. After your first entry in the url 
bar, it will try to complete subsequent entries to that first one no matter what they are. It settles down after a couple entries which 
is why y'all may not see this every time.

anyway, this is radha's bug, and its just a bug, you don't "completely remove" a feature cuz it has a bug.

Comment 8

[Radha on family leave (not reading bugmail)]

I'm aware of this. will look in to it after my feature work is done

Comment 9

[Stephen Walker]

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

Comment 10

[Asa Dotzler [:asa]]

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

Comment 11

[George Kommet]

One additional interesting behavior.  If you type in a URL like www.joeblow.com,
go there, and then hilight the joeblow to overtype it with fubar (want to go to
www.fubar.com now), as soon as the autocomplete "suggestion" pops up the cursor
is moved to just before the >>, so you get "www.f.comubar >> www.joeblow.com" in
the Location field.  The cursor should stay wherever the last typing occured, IMHO.

Comment 12

[Dave]

cc self

Comment 13

[Radha on family leave (not reading bugmail)]

Fix checked in for the incorrect autocompletion problem. As far as the ">>" goes 
the autocomplete widget adds that. For example, 

1)if the urlbar history has the entry "www.mozilla.org" in it and then you type 
"mozil" OR "http://www.moz", ubhistory component returns www.mozilla.org as a 
possible match. and the autocomplete widget appends >>www.mozilla.org. to 
whatever you typed in.

2) if ubhistory has www.mozilla.org and you type "www.mo", then the >> won't 
appear. You will see www.mozilla.org with "zilla.org" highlighted. 

3) Assuming you have www.mozilla.org/community.html and 
www.mozilla.org/feedback.html in the ubhistory and you type mozil, you will see 
a "mozil>>" followed by the first match found AS WELL AS a pop-upmenu at the 
bottom of urlbar showing the 2 possible matches and you can choose from one of 
them. If you just press enter at this point instead of choosing one from the 
pop-up menu, the first match found will be loaded.

ducarroz owns the autocomplete widget. Please let me know if this >> still 
bothers you. I'll talk to ducarroz about it. Nothing has been done regarding the 
problem that George Kommet has described.

Comment 14

[Dave]

I'm still of the opinion, as I stated in my bug which is a dup of this one, that
the browser shouldn't go to the first match upon hitting enter... it shouldn't
go to autocompleted urls unless you explicitly tell it too in some fashion (hit
'end' key, etc).
There have been many ocassions when I have wanted to go to, say, www.foobar.com
and it has autocompleted www.foobar.com/baz/fred.html or something similar,
forcing me to delete the extra "baz/fred.html" and try again. What's more, when
I delete "baz/fred.html," it will again try to autocomplete the url with the
same results.
This is just my personal opinion though :)

Comment 15

[Blake Ross]

I also don't think we should use the >> method, it feels sloppy.  What's wrong
with the way IE does it?  Namely, finish what they're typing with the most
likely entry, and bring up a menu beneath it with other possibilities.  Radha,
is that autocomplete menu ever coming back?

Comment 16

[Radha on family leave (not reading bugmail)]

If there are multiple matches the menu does open up. I saw it working yesterday. 

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The url-bar still adds the ">> something" sometimes. It seems to do a search for
entries in the history which contains the sofar-entered-url as a substring. I
can't see any reason for keeping this >> functionality, the dropdown is much
better once it works.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

with dropdown I mean the autocomplete menu...

Comment 19

[Radha on family leave (not reading bugmail)]

>> is the autocomplete widget feature. cc'ing ducarroz. I don't think this is a 
beta3 priority. 

Comment 20

[Bill Law]

[nsbeta3-], based on Radha's comment.

Comment 21

[Ben Bucksch (:BenB)]

Bug 51910 is related.

Comment 22

[Radha on family leave (not reading bugmail)]

The >> problem was fixed last week. marking this fixed.

Comment 23

[sairuh (rarely reading bugmail)]

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