217640 - autocomplete removes exactly matching entries from list

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[Jeremy M. Dolan]

I have two user names saved for a site, say, "foo" and "foobar". When I type
"f" into the usern ame field, both are shown. When I type another "o", no
change. When I type the second "o" so that it now reads "foo", my "foo" user
name disappears from the drop-down list, and only "foobar" remains.

Expected behavior would be to still show both matching entries. A user may type
the first part of an exactly-matching entry quickly, THEN look at the list and
be shocked to not see it. Also, the password field doesn't fill-in to match this
now "chosen" entry until the blur event, so it looks as if there is no "action"
to be taken still (since you can't arrow down and hit enter), so users may be
confused about the password not being present if the entry is already "selected".

The URL bar behaves as expected. Typing http://www.nytimes.com/ there shows
"http://www.nytimes.com/" as well as "http://www.nytimes.com/etc/etc/etc".

Passwords and form fields do not.

Comment 1

[José Jeria]

Maybe I misunderstood you, but in your example, why show foo in the
autocomplete, when you already typed it in? 

Comment 2

[Jeremy M. Dolan]

Because it still matches, because the password hasn't been set yet, and because
it's jarring to see something that matches disapear from the list of matches.

Comment 3

[David P James]

This may be intended behaviour. It seems like it to me since it removes a
'superfluous' entry. If it isn't it's minor.

-->Minor

Comment 4

[Jesse Ruderman]

I thought this was a little weird the first time I saw it in Firebird, but IE
does the same thing.

Comment 5

[Jeremy M. Dolan]

"IE does it" doesn't apply here so much.

Since
 a) both Jesse and I thought this behavior was weird/unexpected
 b) leaving the match gives users more options that match their input:
     1) having one extra valid or arguably-valid selection is never bad
     2) removing one valid selection can be quite bad

I think Mozilla/wallet/satchel/whatever should modify its behavior here, to
match URL bar behavior, and provide the expected selection list.

Comment 6

[Jesse Ruderman]

I agree with jmd - fixing this would be an improvement.

Comment 7

[Ben Goodger (use ben at mozilla dot org for email)]

worth investigating, if only briefly. 

Comment 8

[Jan Varga [:janv]]

Yeah, I think it was done this way intentionally, to match IE probably.
See
http://lxr.mozilla.org/mozilla/source/toolkit/components/satchel/src/nsFormHistory.cpp#803
The fix for this bug would be really easy, just remove that check for strings of
the same length.
Ben, do we want to change the current behaviour?

Comment 9

[Jan Varga [:janv]]

Attachment: fix

Comment 10

[Jan Varga [:janv]]

Comment on attachment 152584 [details] [diff] [review]
fix

Ben says r=ben

Comment 11

[Jeremy M. Dolan]

Comment on attachment 152584 [details] [diff] [review]
fix

Can you sr, blake?

Comment 12

[Jan Varga [:janv]]

Comment on attachment 152584 [details] [diff] [review]
fix

landed on the trunk long time ago with r/sr=ben

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 152584 [details] [diff] [review]
fix

a=[e-mail]

Comment 14

[Jan Varga [:janv]]

fixed on the trunk and aviary branch

Comment 15

[Jeremy M. Dolan]

Verified fixed. Very nice improvement. Thanks Jan! (et al)

Comment 16

[Martijn Wargers (dead)]

Hmm, I thought this was a bug in Firefox not matching IE's behavior (which I
prefer).
When I paste some word in http://lxr.mozilla.org/seamonkey/ in the text
search/file search input, and I used this word already some time ago, I get the
autocomplete popup. That is extremely annoying in this case, because it blocks
me from clicking the find button.

Comment 17

[Jeremy M. Dolan]

Martijn: Clicking anywhere, inside or outside of the block, removes the
drop-down. Hardly a major issue, and forms with the submit button right below
the input area are rare, for this very reason. If there was more than one match,
even in IE, the submit button would be blocked.

Perhaps though, a paste operation into an input that only matches a single saved
entry should not cause the drop-down to be created? The purpose of this bug was
not to remove the current value from the drop-down if it was already shown, but
actually creating the drop-down if it wasn't already shown could perhaps be a
different case.

Anyway, a seperate issue, and fairly trivial.

Comment 18

[Keith Lea]

I filed the behavior mentioned in comment 16 as bug 262206.

Comment 19

[Adam Guthrie]

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