178597 - autocomplete="off" support

Status: VERIFIED FIXED

(Firefox :: Address Bar, enhancement)

Description

[Todd Boland]

Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021105 Phoenix/0.4

Note: I'm not even 100% sure autocomplete="off" is infact standards compliant.

To Reproduce: Create a form with an input type="text" feild which contains the
autocomplete="off" attribute (ie: <input type="text" autocomplete="off"
name="foo" />). Type something and submit. Re-type that same value and voila,
you still get autocomplete.

Expected Results: The autocomplete feature would not be queued.

Comment 1

[André Dahlqvist]

Todd, two things:

1) Can you attach a testcase that shows this behaviour?
2) Do you see the same behaviour with latest nigthly builds of Mozilla?

If 2 is true, please reassign this to the appropriate Mozilla component.

Comment 2

[David P James]

Reporter: Presumably you have created such a form somewhere or know of a place
where one exists, so please either post a test case or provide a link to a known
form of this type. We cannot confirm this bug if we are unable to recreate the
bug, regardless of whether it is a Phoenix or a Mozilla bug. My knowledge of
HTML is insufficient to create the type of form you want us to create. All I can
manage from your description is a blank text field.

Besides that, I'm not getting Autocomplete working anywhere, so it may be broken.

Comment 3

[Todd Boland]

I can't figure it out. Sometimes autocomplete works, sometimes it does not. On
google's homepage, autocomplete works. On some of my own forms on itodd.org, it
works fine. Yet when I try to reproduce this bug @ http://itodd.org/178597.html
it does not work at all. 

I can no longer reproduce this specific bug.

Comment 4

[David P James]

I remember now... Autocomplete is broken when not in the leftmost tab, it's a
known bug. I tried your link and I can now reproduce the bug in the first tab;
Autocomplete was working for both fields.

Next we have to determine if autocomplete="off" is standards compliant or not.
If it is, I'll confirm this bug. If it isn't it'll get marked as INVALID.

A preliminary Google searche on it turns up a few pages at microsoft.com, so
it's not looking good...

Shamelessly lifted from
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie50/html/ACoff.asp

"What the Web Author Can Do

"With AutoComplete, we [that would be Bill & Co] introduced a new attribute that
can be used in <FORM> tags. The attribute is "AUTOCOMPLETE," and when it is set
equal to "OFF," AutoComplete will not be used for the entire form that follows."

Likewise, from
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie50/html/VCARD.asp

"Cross-Browser Compatibility [bad joke this is]

"With AutoComplete, you don't need to author twice and you don't need to detect
browsers. Because AutoComplete adds a new attribute to the HTML INPUT tag, older
browsers, such as Internet Explorer versions 3.x and 4.0 and all Netscape
Navigator browsers [note: *all*, which presumably includes 6.x & 7.x and
therefore Mozilla & Phoenix], will simply ignore it. You will not affect your
reach at all by adding AutoComplete support. Plus, it's very simple to add
AutoComplete support."


So, my guess is that autocomplete="off" isn't standards compliant. However, if
you like you can change this into an enhancement request and I'll confirm that
for developer review (just drop the (broken?) bit from the summary).

Comment 5

[David P James]

-->Confirming enhancement request as new for developer review

Comment 6

[David P James]

Oops, that should be all OSes.

Comment 7

[André Dahlqvist]

David, what makes this bug not a dupe of bug 177797?

Comment 8

[David P James]

This bug refers to an attribute type in a form that Microsoft has devised known
as "autocomplete", which can take on values of "on" (default I guess) and "off",
which is what the reporter is asking about. If set to "off", then IE will not
offer/attempt to autocomplete the form field, but Phoenix will. So the question
is whether or not Phoenix will support this new form field attribute that
Microsoft has devised. The W3C validator doesn't like the attribute
"autocomplete", so probably not? [as an editorial aside however, this isn't the
worst idea in the world for sites like Google that are continually offering
previous searches in Phoenix when one is attempting to run a new search].

Complicating this in comment #3 and comment #4 is the fact that autocomplete for
Phoenix is not working beyond the first tab, which is bug 177797.

Comment 9

[Sébastien Delahaye]

It wouldn't be standard-compliant. Resolving as INVALID.

Comment 10

[jacob c]

Support for the autocomplete attribute is advertised as supported by Netscape 6+
on the Devedge site:
http://devedge.netscape.com/viewsource/2003/form-autocompletion/

I'm sensitive to the fact that this is a non-standard attribute, but, IMHO, it
seems like not supporting this would be a disservice to web developers who will
expect similar behavior between Firebird and Navigator, at least on an issue
like this.

Comment 11

[Simon Paquet [:sipaq]]

Reopening. Jacob has good point in Comment 10.

Comment 12

[David P James]

To confuse matters further, bug 198419 suggests that there is some support for
this in Mozilla as well. The point is made that some banking institutions have
made requests for this feature.

Comment 13

[Simon Paquet [:sipaq]]

I can reproduce this with the 20030714 build.
Testing with https://webmail.t-online.de

You don't have to know a correct username to test this. Just type "test" into
the "eMail-Adresse"-field and press the login-button. You will be told (in
German) that login failed. Delete the "test"-entry and type it again.
Autocomplete will come up.

Comment 14

[David P James]

Taking QA. Sorry for the bugspam

Comment 15

[David P James]

Attachment: autocomplete="off" in <form> element - still autocompleting

We seem to have partial support for autocomplete right now, perhaps as a result
of bug 201850. If autocomplete="off" is in a <form> element, autocomplete still
functions (this is how DevEdge recommends it be done). If, on the other hand,
it is within an <input> element, autocomplete is disabled. I suspect Ben did
this in bug 201850

Comment 16

[David P James]

Attachment: autocomplete="off" in <input> element - not autocompleting

Now try with this, where autocomplete="off" is in an <input> element. No
autocompletion.

Comment 17

[David P James]

Reassigning to Ben since it pissed him off enough to do something about it in
bug 201850 :)

Comment 18

[Blake Ross]

-> bryner

Comment 19

[David P James]

Cleaning up summary and removing now-dead test case URL.

Comment 20

[Brian Ryner (not reading)]

fix checked in.

Comment 21

[David P James]

v.