272002 - Autocomplete dropdown appears when the password manager fills in passwords

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Tom Simnett]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When a login page that has been logged into before and therefore captured data
is re-browsed, for example to log in again, the browser drops down a list of the
data entered into the input type="text" element. This only happens when there is
an onload=<element>.focus() style piece of javascript either in the onload part
of the body tag, or within a script tag. It does not happen when the focus()
function is not called.

Reproducible: Always
Steps to Reproduce:
1. Go to a page with a login and a focus() on the login element when the page loads.
2. log in
3. Log out
4. Log in again

Actual Results:  
The drop down appears with a list of usernames used, even if there is only one.

Expected Results:  
The site should not drop down this list if the text is within an onload
attribute of the body tag. This action often hides other form elements and means
that the user has to physically hide it to reveal other options, such as
password fields etc, or even the submit button.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

I can confirm this behavior. I'm not sure whether or not it was intentional.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

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

Comment 3

[:Gavin Sharp [email: [e-mail]]]

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

Comment 4

[Brian Ryner (not reading)]

Attachment: patch

The real problem here is that setting an input's value programatically
generates an oninput event.  I don't believe this is correct behavior; see
http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-EventTypes-complete
for the description of the "textInput" event, which our oninput event closely
matches.

This change suppresses firing oninput from the editor's notifications when we
are setting the value ourselves.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 174182 [details] [diff] [review]
patch

r+sr=bzbarsky

Comment 6

[Brian Ryner (not reading)]

-> core so that I can set the approval flag

Comment 7

[Brian Ryner (not reading)]

Comment on attachment 174182 [details] [diff] [review]
patch

requesting approval, this is a pretty safe fix.

Comment 8

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 174182 [details] [diff] [review]
patch

a=caillon for 1.8b

Comment 9

[Brian Ryner (not reading)]

Checked in.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Are you sure Web pages don't rely on oninput working the way it did?  How does
it work in IE?

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Or does nobody else implement it?  What does the spec say we should do?

Comment 12

[:deanis74]

I read the textInput section differently.   "One or more characters have been
entered. The characters can originate from a variety of sources."  Isn't
auto-filling them just another source?

Comment 13

[Scott MacGregor]

This patch broke autocomplete for Thunderbird and the mozilla suite. Please see
Bug #282645 for details.

Comment 14

[Brian Ryner (not reading)]

(In reply to comment #10)
> Are you sure Web pages don't rely on oninput working the way it did?  How does
> it work in IE?

IE doesn't seem to have this event.  Another reference for this behavior can be
found on the Web Forms 2.0 draft specification
(http://www.whatwg.org/specs/web-forms/current-work/#the-change), which says:
---------
In addition, to address the need for even more immediate feedback mechanisms,
this specification introduces the input event. This event is fired on a control
whenever the value of the control changes due to input from the user, and is
otherwise identical to the change event. 

...

Change and input events must never be triggered by scripted changes to the
control value. Thus, loops caused by change event handlers triggering changes
are not usually possible.
---------

Comment 15

[PikeUK]

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

Comment 16

[Elmar Ludwig]

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

Comment 17

[Boris Zbarsky [:bzbarsky]]

It looks like this patch caused bug 289425.