Closed Bug 40643 Opened 25 years ago Closed 24 years ago

Location bar autocomplete ignores my input and does wrong thing

Categories

(SeaMonkey :: UI Design, defect, P2)

x86
All
defect

Tracking

(Not tracked)

VERIFIED FIXED
Future

People

(Reporter: selmer, Assigned: radha)

References

Details

(Keywords: helpwanted, Whiteboard: [nsbeta3-])

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???
This is using build 2000-05-25-08 on NT.
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.
QA Contact: sairuh → claudius
*** Bug 40845 has been marked as a duplicate of this bug. ***
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
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 >>
Severity: normal → major
OS: Windows NT → All
*** Bug 40305 has been marked as a duplicate of this bug. ***
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.
Assignee: don → radha
I'm aware of this. will look in to it after my feature work is done
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → M17
*** Bug 42733 has been marked as a duplicate of this bug. ***
*** Bug 39800 has been marked as a duplicate of this bug. ***
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.
cc self
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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 :)
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?
If there are multiple matches the menu does open up. I saw it working yesterday.
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.
Severity: major → normal
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
with dropdown I mean the autocomplete menu...
Status: REOPENED → ASSIGNED
Target Milestone: M17 → Future
>> is the autocomplete widget feature. cc'ing ducarroz. I don't think this is a beta3 priority.
[nsbeta3-], based on Radha's comment.
Whiteboard: [nsbeta3-]
Bug 51910 is related.
The >> problem was fixed last week. marking this fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
No longer blocks: 78270
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 → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.