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)
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???
Reporter | ||
Comment 1•25 years ago
|
||
This is using build 2000-05-25-08 on NT.
Comment 2•25 years ago
|
||
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.
Updated•25 years ago
|
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
Comment 5•25 years ago
|
||
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
Comment 7•25 years ago
|
||
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
Assignee | ||
Comment 8•25 years ago
|
||
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
Comment 10•24 years ago
|
||
*** Bug 39800 has been marked as a duplicate of this bug. ***
Comment 11•24 years ago
|
||
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•24 years ago
|
||
cc self
Assignee | ||
Comment 13•24 years ago
|
||
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
Comment 14•24 years ago
|
||
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•24 years ago
|
||
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?
Assignee | ||
Comment 16•24 years ago
|
||
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...
Keywords: nsbeta3
Assignee | ||
Updated•24 years ago
|
Status: REOPENED → ASSIGNED
Target Milestone: M17 → Future
Assignee | ||
Comment 19•24 years ago
|
||
>> is the autocomplete widget feature. cc'ing ducarroz. I don't think this is a
beta3 priority.
Updated•24 years ago
|
Keywords: helpwanted
Comment 21•24 years ago
|
||
Bug 51910 is related.
Assignee | ||
Comment 22•24 years ago
|
||
The >> problem was fixed last week. marking this fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 23•22 years ago
|
||
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
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•