Closed Bug 194574 Opened 22 years ago Closed 19 years ago

preview of autocomplete selection not right (capital/lowercase letters)

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jmd, Unassigned)

References

Details

On http://www.mapquest.com/directions/
For the city field, if I type a 'c', "Chicago" shows up as the only saved
choice. I hit the down arrow to select it, and in the actual field, "cago" is
displayed (none of the word is selected/highlighted). That's my first letter
then the last three of the store choice. When I actually hit enter it is then
shows as "Chicago"

And in the next field, I type 'i', "IL" is displayed as saved. I hit down arrow,
and "il" is shown (Notice case). When I hit enter it capitalizes itself to "IL".
Reporter, please report bugs correctly before auto-confirming them. This one's
missing the version you're using.

Besides, this is WFM with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.4a) Gecko/20030313 Phoenix/0.5.

Could you try with the latest nightly and a new profile, please?
This is still broken in yesterdays build.

Gecko/20030317 Phoenix/0.5 Linux
I can repro this on Win98 build 20030312: (OS->All)

Happens in the URL autocomplete as well as form autocomplete.

It's more than just the preview of the selection, though.  If you don't hit
enter to select the (previewed) entry, but rather use an arrow key or click, the
bad entry stays in the form element, which you can then submit.

Testcase Steps (using the URL bar):
0. Make sure you have several (lower-case) history items for mozilla (eg
http://bugzilla.mozilla.org/, http://www.mozilla.org, http://www.mozillazine.org/)

1. clear the URL bar

2. start typing MOZ

3. dropdown appears with *mozilla* entries

4. arrow down the list

Note the 'preview' URL shown is strange.
If you press enter or click on an entry, a 'good' URL is navigated to.
If you click in the URL bar or use l/r arrow, the 'bad' URL stays, and would be
navigated to when hitting enter (or GO).
Still a problem after the fix in bug 212686. Brian, perhaps you'd be interested
in this one too?
Summary: preview of autocomplete selction not right → preview of autocomplete selection not right (capital/lowercase letters)
*** Bug 210961 has been marked as a duplicate of this bug. ***
Taking QA. Sorry for the bugspam
QA Contact: asa → davidpjames
> For the city field, if I type a 'c', "Chicago" shows up as the only saved
> choice. I hit the down arrow to select it, and in the actual field, "cago" is
> displayed (none of the word is selected/highlighted).

Sounds similar to bug 202992, "h" or "htt" cut off in address bar autocomplete.
*** Bug 214770 has been marked as a duplicate of this bug. ***
The best place (as always) to test this out is at google. Enter a couple of CAPS
ON searches, then go back and start typing out one of those searches with lower
case letters. Use the down arrow to select one, and you get something like
mMOZILLA. If, on the other hand, you start typing in upper case, then select an
entry that begins with lower case, you get something like Mmozilla.
OS: Linux → All
This bug is confusing.

comment 0 is about Chicago>cago

comment 3 is about MOZtp://www.mozilla.org/

bug 202992 which looks like almost like above

and duped bug 214770 about mMozilla

someone cleanup so I won't be confused
comment 3
comment 0
comment 8
seem very different to me.(all reproducable
Would it be easier for each of the 3 comments 0, 3 and 8 to be tracked as
separate bugs instead of 1 single bug. This will ensure that all the cases we've
observed are addressed. We have bug reports filed for each of the 3 cases and
though my immediate hunch is that the fix for 1 will fix the others, bundling
all cases into one bug might make the fix seem tricky.
Can we please stop all this? Comment 3 and comment 8 are simply different
reflections of the same problem, as I explained in comment 9 (the issue is case
sensitivity). Comment 0 gave me a little trouble too, but then I looked at bug
210961 comment 5, in which the reporter of this bug dupes that bug against this
one. Bug 210961 is very similar to what I described in comment 9, so if Jeremy
believes them to be the same, I'm inclined to go along with it.

To confuse matters still further, bug 202992 is also similar in some respects.

Now, please, no further comments on describing the nature of this bug or its
various incarnations. If you've got information on the source of this bug in the
code, or suggestions on how to fix it, then please contribute. If not, please
just quietly add yourself to the CC: list.

Thanks
cago bug
========
1. http://www.mapquest.com/directions/
2. type chicago in city
3. Reload
4. type C
I get Cchicago
=======
1. http://www.mapquest.com/directions/
2. clear form data
3. type Chicago in city
4. reload
5. type c
I get cago
That's still a case sensitivity issue. When you typed 'c' it was enough for
autocomplete to detect the "C" of "Chicago" but when you arrowed down the case
sensitivity bug kicked in and went to the first small 'c' it could find - hence,
"cago". The same would happen with "Toronto". But where the first letter doesn't
make a second appearance, "Ottawa" for example, it just shoves the smaller case
letter off the front, hence something like "oOttawa".
*** Bug 219312 has been marked as a duplicate of this bug. ***
We need a new assignee
*** Bug 233553 has been marked as a duplicate of this bug. ***
*** Bug 237054 has been marked as a duplicate of this bug. ***
Using 20040403's build, I don't see this anymore.. Anyone else?
WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040403
Firefox/0.8.0+
Confirmed WFM 20040330 Firefox/0.8.0+, Win XP.

For form fields, it actually changes the case of the typed text to the same case
as the selected option (e.g. 'C', becomes 'chicago' not 'Chicago' in the above
example). In the history of the location bar, it seems to retain the upper case
text for the typed part (so you could end up with 'MOZilla.org').

Even though the behaviour is slightly different for the two fields, I guess it's
suitable, since location info isn't usually case sensitive. One thing I noticed
was that once I had 'chicago' stored in the field info, I couldn't seem to get
it to save 'CHICAGO' as well... but perhaps that's a separate bug?
Assignee: hewitt → nobody
QA Contact: davidpjames → location.bar
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.