
Issue 914451: Autofill does not respect autocomplete="off" - bullman
https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c73
======
romaaeterna
A few years ago, I left a $1000 tip at the restaurant up the street because
Chrome filled out the tip field with my zip code (which thankfully merely
defaulted to max $1000 instead). The tip field was off-screen, and the
ordering software didn't have a confirmation screen, just a "we just charged
your card $X amount" screen, which made my eyes boggle.

EDIT: Looking at the original March 17th, 2015 bug, it would have been at
exactly around that time...In fact, checking my emails, this happened on March
18th, 2015. I had ordered from them several times before this with no problems
(they used "chownow.com" for their ordering backend).

~~~
dmethvin
This has a lot of really serious implications. I built a form for a charity
that allowed users to buy a subscription but include an additional donation
amount. Chrome was sometimes filling that field with the two-digit year. The
charity got a lot of complaints and it ruined the trust relationship with the
donors who didn't understand what was happening and thought it was
intentional.

~~~
mikorym
Chrome has other behaviour that I think violates a sort of trust relationship.
One of which is that Youtube would ask you "do you want to install Chrome"?
Almost as if your current browser is not "what you need to access Youtube".
This is especially a problem for elderly people who often use the web but
don't really understand how things fit together (the way 5 year olds actually
do).

~~~
smt88
> _Almost as if your current browser is not "what you need to access Youtube"_

This is not just confusing. It's intentionally misleading and unethical.

And it doesn't just affect old people, or YouTube wouldn't have come up with
it. Lots of young people grew up with computers and understand how to do what
they want to do, but they never develop a systematic understanding of what
they're using.

It gets worse, though. While we tech-folk know that all modern browsers are
supposed to have near-parity, Google optimizes its sites for Chrome, leading
to additional confusion for both knowledgeable and lay users.

------
carstenhag
As I had already commented on the issue, it completely breaks Germany's main
train ticket selling website:

[https://i.imgur.com/BjYTgSn.png](https://i.imgur.com/BjYTgSn.png)

They have tagged the field as autocomplete=off but Chrome just doesn't care.

Also see this linked issue where they collected valid use cases for
autocomplete=off. They just seem to ignore 452 use cases (I can't comment on
the quality of them, I did not read any).

[https://bugs.chromium.org/p/chromium/issues/detail?id=587466](https://bugs.chromium.org/p/chromium/issues/detail?id=587466)

~~~
watwut
Imo, valid use case for autocomplete=off is "the developer of webapp wants
it".

Literally that and nothing more.

~~~
Nitramp
It's called "user agent", not "developer's agent". We'd be in a terrible
situation if the browsers just followed developer's whims. Cf. popup blocking.

~~~
sky_rw
Dismissing the above use cases as "developer's whims" is the fundamental issue
most people here are taking with these decisions.

I think we can all agree that browser behavior should not be left solely up to
the developer and is not a black and white issue. Nobody here is arguing that.
We are arguing for following a guideline that makes sense. This is why we have
the w3c, an organization that attempts to weigh the needs of user, developers,
and browser maintainers.

~~~
TeMPOraL
The issue is that the browser is supposed to be the meeting place for
negotiating between developer and user preferences. Its job is to take into
account preferences of both sides, and render the site accordingly. _Not_ to
be a third party at the negotiating table. Breaking agreed standard in a way
that can't be overridden by the user? Browsers should never do that.

~~~
muro
In this case, it can be overridden by the user, just not the developer :)

~~~
xg15
Not really if the user is non-technical and doesn't even know they'd have to
override it.

~~~
basch
"this website has asked us to NOT autofill your saved info.

if you would like to autofill the form anyway click"

i made it a little terse, but there has to be a way to make it succinct and
human readable.

~~~
xg15
I think this could still be confusing as enough users will likely have no idea
who "us" is in that message - if they understand the difference between
browser and website at all. It could also be confusing if the website already
provided its own autocompletion via JS: The user would get a message that
autocomplete is turned off while they see that it seems to be right there.

But I think in general, some kind of prompt or override would work. I
absolutely agree that if a user _wants_ to use the browser autocomplete
functionality, they should have an option to do so. I have no understanding
for websites that just want to disable autocomplete without replacement.

However the concerns seemed to be about autocomplete being incorrect or
conflicting with application-provided lists. I can see how that leads to
frustration and confusion with users.

The Chrome team seems to trust its algorithm to an amount where they don't
seem to find it necessary to deal with incorrect results - a view which
doesn't match reality apparently.

------
sandstrom
This has turned into a sad chicken-race between Google and developers, with
lots of innovative workarounds on Stackoverflow.

Their tactic of overruling web developers doesn't work, it only make things
more complicated for everyone, since many of the workarounds have other
negative side-effects.

[https://stackoverflow.com/questions/12374442/chrome-
ignores-...](https://stackoverflow.com/questions/12374442/chrome-ignores-
autocomplete-off)

    
    
        ## Example 1
    
        For a reliable workaround, you can add this code to your layout page:
    
        <div style="display: none;">
         <input type="text" id="PreventChromeAutocomplete" 
          name="PreventChromeAutocomplete" autocomplete="address-level4" />
        </div>
    
        Chrome respects autocomplete=off only when there is at least 
        one other input element in the form with any other autocomplete value.
    
    
    
        ## Example 2
    
        Simply make your input readonly, and on focus, remove it. This is a very 
        simple approach and browsers will not populate readonly inputs. 
        Therefore, this method is accepted and will never be overwritten by 
        future browser updates.
    
        <input type="text" onfocus="this.removeAttribute('readonly');" readonly />
    
        Style your input accordingly so that it does not look like a readonly input.
    
    
        ## Example 3
    
        Tell Chrome that this is a new password input and it won't provide 
        old ones as autocomplete suggestions:
        <input type="password" name="password" autocomplete="new-password">

~~~
obituary_latte
I think it mentioned chrome is even now ignoring ‘display:none’ and
‘visibility:hidden’ declarations so those workarounds no longer work either.

~~~
msclrhd
Great! :( Now I need to recheck to see if an autocomplete bug has reappeared
where it thinks an email address field is a username field in a change
password UI and autocompletes the email address with the username from the
login page.

Sigh!

~~~
obituary_latte
I feel your pain - sorry you have to deal with it. I’m working on a client
data management app and I’m having issues _everywhere_ with this. It’s been an
open ticket on Jira for _months_!

------
ss3000
Setting aside the merits/lack-thereof of this particular decision, Chromium
ignoring established web standards like this is especially dangerous as we're
trending towards a world where 1) Chromium itself powers the most popular
browser in the world by an increasingly unhealthy margin, and 2) even
competing browsers are increasingly becoming skins on top of Chromium.

We are becoming more and more reliant on the developers of Chromium to be
steadfast stewards of the standardization process. Their massive influence
means that any deviation from actual web standards on their part will
inevitably create a new and conflicting de-facto standard that will create
decades of lasting damage and irreversible tech debt for the entire web
(eventually leading to a repeat of the IE6 dark ages).

Decisions like this demonstrate an utter disregard for the crucial role
Chromium plays in the web standardization process, and jeopardizes the entire
ecosystem.

~~~
ko27
Strictly speaking, Chrome is not ignoring a web standard, since the standard
does not require this behavior (no "MUST" keyword).

~~~
obituary_latte
Well they _are_ ignoring hundreds if not thousands of developers which is the
main issue at this point.

~~~
jrockway
By ignoring "hundreds if not thousands of developers" they are respecting the
wishes of millions of end-users that don't want the site owner to decide what
they can and can't autofill.

Obviously a simple boolean is the wrong design here. But can you suggest a
better one?

~~~
fuzzy2
I don't think "millions of end-users" want broken websites because now another
developer (Google) gets to decide what's correct (instead of the web dev).

A better solution could be to just behave reasonably by default but allow the
user to re-enable auto-fill with a single click.

------
jchw
Because other people here are throwing in their frustrations, I will at least
add that on the flip side I have been frustrated by sites that attempt to
disable autofill for illegitimate reasons, like attempting to disallow
password managers. I think I understand where this is coming from.

On the other hand, I, too, have been bit by this at least once, in the past. I
think it was easier to just disable it at that time, but IIRC, the solution we
landed on was to not use form controls at all but switch said text controls
over to use content-editable elements. In our case it made sense, since it was
not a form at all. My memory could be a bit hazy here, though.

(I do not work on Chrome or use Chrome at home, but as disclosure I do
currently work at Google.)

~~~
anoncake
I think we need a way to disable features only for those developers that abuse
them. Like uMatrix but built-in and with rules being supplied automatically as
ad blocking lists are.

You autocomplete=off a password field? That attribute won't have an effect on
your site anymore.

You auto-play videos when the user doesn't expect it? What videos? The web
doesn't support videos – as far as you are concerned.

Scroll hijacking? I hope you used progressive enhancement because you just
lost your Javascript privileges.

~~~
msclrhd
Can we have a reliable cross-browser way to say "this is a change password
field, so don't autocomplete it" and "this is an email address field not a
username field, so don't autocomplete it with the login username"?

~~~
shdon
The autocomplete="new-password" (or autocomplete="off" or even
autocomplete="some-random-nonsense") method is supposed to be doing that
according to the spec. It is ignored by browser developers probably due to
abuse. Additionally, all of those also trigger the prompt to save the
password. For a password change form, that is the right thing to do, for many
others it is not.

I'd very much like to see a way to disable that save prompt too, especially in
user management screens. When I create a new user, I want neither my own
password to be autofilled, nor do I want to overwrite my saved password with
theirs.

------
azernik
I ran into this last week (with LastPass, not Chrome - this seems to be a
common practice):

I have a form where users enter information about their suppliers (I make
restaurant management software). This includes a field for the contact email
address, which LastPass was autofilling the email address the user used to log
in. This happened silently, quickly enough that users wouldn't notice it on
page transition, and would _overwrite the initial value_. Even with
autocomplete=off.

This was a DATA LOSS bug - users would load the page, make a few changes,
save, and not notice that they'd lost the email address they'd stored for the
supplier. Fortunately LP has a method to force disabling of autofill (data-
lpignore=on), but this could have all been avoided if they'd _followed the
spec I was relying on_. I still don't know if some other password manager,
maybe built in to Firefox or something, will make the same mistake, haven't
had time to check yet.

~~~
notatoad
The LastPass on is especially horrific because it fills in fields that are
already filled, _and it fires a change event_. So if you're auto-saving on a
change event, that data is lost as soon as the page is loaded.

~~~
kerng
The entire design of password managers that hijacking the DOM is flawed.

~~~
SaladFork
A recent LastPass version does not fail gracefully and a lot of my webapps
started getting weird console errors from users with LastPass extensions that
were trying to unsuccessfully inject into our forms. :/

------
Geeflow
As a user, Chrome's autocomplete went down the drain for me once they started
to fill all fields at once. I tried to autocomplete one field and often chrome
filled the other fields with unfitting data. This happened so often that I
started to manually complete fields even if autocomplete was available. I
still miss the good old times[tm] of single-field autocomplete...

(And for the record: As a developer, I have been bitten by Chrome ignoring
autocomplete="off" as well.)

~~~
megous
Yup, I like how FF does it. I basically just do a repeated sequence of:

TAB -> Arrow Down (select one of the previously filled values I've used) ->
Enter

When filling a form. Given that sometimes we order things on made up names,
it's quite useful no to have that autofilled when we're not wanting to.

------
TekMol
I guess this will lead to a horrible coding style where instead of having this
in the form:

    
    
        <input name="email">
    

We will see stuff like this:

    
    
        <input name="16fkr9547kancot944128sddfksdf934998aafccugt75">
    

Where developers use some type of abstraction that generates a random id for
each field and then assigns it to the original value server side or in
javascript.

Just like they already randomise asset filenames to avoid caching.

~~~
StavrosK
Your comment about randomizing filenames got me thinking. It would be great if
we could add a cache key to the HTML element, that way we could cache
everything forever with the same filenames and still invalidate things by just
making the key being the SHA of the deploy. Too bad that's not a thing.

~~~
jstanley
That is a thing already!

[https://developer.mozilla.org/en-
US/docs/Web/Security/Subres...](https://developer.mozilla.org/en-
US/docs/Web/Security/Subresource_Integrity)

~~~
StavrosK
Subresource integrity is for ensuring that you got the right file (it fails if
you didn't), it doesn't do anything with the cache, unfortunately.

~~~
jstanley
Really?

Seems like it would be crazy _not_ to use it for caching.

~~~
summm
The problems are 1) side channels. Caching those would mean that a malicious
script could use timing to find out if the user accessed specific other
websites. Also it enables a channel for cross-domain communication. 2)
malicious user tracking would not work as well anymore, which would be good
but Google probably will not support that. Currently they get all those nice
http log entries from sites that only include fonts etc.

~~~
Natanael_L
For sensitive files with known names, you should be able to set that the cache
is only valid for requests from the same host website (as the server might
decide to send another response when the host is different). That would fix
the sidechannel.

------
VMG
Autofill for offscreen elements gives me the creeps even without the data
getting misinterpreted

~~~
dmix
This is why form elements should never be hidden _after_ loading. Display none
should be the default in the HTML for non-relevant content, which should be
enough for most autofillers. It also prevents flashing of content when
autofillers try to populate it, causing the hiding to delay, which I recently
saw in a production app.

Frameworks like React and Vue don’t even render the HTML into the DOM until
conditions are met so the situation is improving.

Another positive step away from jQuery hackery!

~~~
pantalaimon
If you want to be malicious and capture wrong auto fill data, wouldn't a
simple AJAX request on change be enough to capture sensitive data before the
user gets a chance to correct it?

~~~
AJ007
Yes, and there are popular third party analytics platforms that record all
activity on a page, which includes not just every key press, but the speed at
which it was done, with or without a submission of the form.

Web browsers should never, ever use auto fill unless the user has already
entered that information on that domain already. Popular domains that host
third party content should never be able to auto fill.

------
sky_rw
Curious as to the global business impact this has had. I personally have spent
at least a dozen hours debugging forms and trying to disable
autocomplete/autofill on my kiosk-based applications. How many development
hours collectively have been wasted on this unilateral decision.

I have not been this frustrated since the days of writing css for ie6, and at
least back then the devs response was more "sorry its our rendering engine"
and not battre just saying GFY seemingly out of disdain.

I try to be as free-market as possible but I sure wish that the w3c had some
teeth when it came to things like this.

~~~
sundbry
You're not the only one. I remember spending a good two days on it this year
for a page where the user puts in their credentials for external integrations.

------
albertzeyer
Btw, at [http://google.com](http://google.com), this is what they have for the
search field:

<input class="..." maxlength="2048" name="q" type="text" jsaction="..." aria-
autocomplete="both" aria-haspopup="false" autocapitalize="off"
autocomplete="off" autocorrect="off" role="combobox" spellcheck="false"
title="Search" value="" aria-label="Search" data-ved="...">

~~~
carstenhag
Does anybody have a clue why it does not show up there? The Google team must
have done something in order to circumvent what the Chrome team did. Horrible.

------
goatinaboat
_Overall, I still believe that neither of the extreme strategies ( "always
honor autocomplete=off"_

Is it “extreme” now for a computer to do what the user wants and not what a
random Google employee wants? How does this differ from malware?

~~~
ProfSarkov
It's also in the spec.

People might not like the spec or it might be incomplete, but adhering to it
is a very important part of improving it until it's a good one.

Now I'm no webdev, but I could very well imagine that the spec is _already_ a
good one. So the situation might be even worse.

~~~
nikanj
The spec only says "should", not "must". Apparently these wingnuts thought
that means the spec can be ignored.

~~~
reificator
> _The spec only says "should", not "must". Apparently these wingnuts thought
> that means the spec can be ignored._

Not arguing in favor of this particular choice, but yes. That is exactly what
"should" means in most cases.

For instance, in RFC 2119:
[https://tools.ietf.org/html/rfc2119](https://tools.ietf.org/html/rfc2119)

> SHOULD _This word, or the adjective "_RECOMMENDED _" , mean that there may
> exist valid reasons in particular circumstances to ignore a particular item,
> but the full implications must be understood and carefully weighed before
> choosing a different course._

~~~
azernik
Blanket disregard of a SHOULD directive as a UX decision neither falls under
"in particular circumstances" nor indicates that they've "understood and
carefully weighed" the consequences.

------
lstamour
The way I see it, autofill off should mean off and if I click the icon in the
address bar to bring up, well, let’s call it “quick access to per-site
settings” then maybe I could override it for a specific page load or site,
like you can Flash, etc.? This per-site configuration is starting to become
“normal” given iOS 13 does the same in Safari for permissions, content
blocking, automatic reader mode, etc. It would make sense that the default is
“follow the HTML5 spec” but you could put a notice in the address bar if you
really felt otherwise...?

Safari does a much better job by only filling visible form fields, I think
(though it too has a tendency to put my address both in Line 1 and Line 3,
which is annoying...).

------
the_pwner224
Explanation from the 'rogue Chromium dev' is linked to in comment 19 of this
bug:
[https://bugs.chromium.org/p/chromium/issues/detail?id=914451...](https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c19)

[https://bugs.chromium.org/p/chromium/issues/detail?id=468153...](https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164)

~~~
antoinevg
...which really makes it worse:

1\. Our programming language has an attribute called "autocomplete" with two
possible values: "on" and "off"

2\. We will now (without consultation or announcement) simply start ignoring
one of those values when you specify it. (and certainly not document the new
behaviour!)

3\. Here, I made you a convoluted (and undocumented!) workaround for getting
the original behaviour of the attribute back.

I'm not sure which horse these FAANG kids who excel at programming challenges
rode in on, but this attitude is RIFE in their product SDK's and API's.

Dijkstra must be spinning in his grave.

~~~
tgv
All that based on an increase in page submissions. Is that the goal of auto-
complete?

The research behind the number (25%) is highly dubious, because the video
cited as the source doesn't tell how it was done. At all. Ironically, it
follows a section on how MDN is documenting the standards, and how that
"contribute(s) a lot".

------
GrayShade
Firefox used to ignore autocomplete="off" until relatively recently. I'm sick
of sites thinking they know better than me -- like those who don't let me
paste in the password field. While I understand the good use cases for this
attribute, given the binary choice I would rather have it ignored.

~~~
mcv
That is absolutely stuff that the user needs to be able to override. In fact,
anything related to cutting and pasting is not something I think the browser
should mess with.

Also: websites that generate a custom login name or password for me so I won't
remember it, and then refuse to allow autofill or pasting. Fortunately dev
tools are standard on the desktop these days.

(I would really, really like access to dev tools on mobile, though. It's
simply necessary to get around some broken websites.)

------
andrewstuart
The weird thing is that there's other teams within Google who offer
autocomplete libraries that simply don't work because Chrome overlays it's own
autocomplete on top.

The maps team seems to have given up on trying to resolve that.

Chrome team have made a judgement that autocomplete is required and no-one -
not even other teams within Google are allowed to override that functionality.

It's weird.

~~~
nikanj
Google really is the new Microsoft

~~~
sixothree
In spirit maybe. But in practice it seems worse.

------
xg15
Relevant reply from a Googler seems to be this:
[https://bugs.chromium.org/p/chromium/issues/detail?id=914451...](https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c66)

by battre@google.com

... which doesn't read at all to me like a "rogue dev" and more like a shared
sentiment inside the Chrome team that autocomplete=off should be ignored.

At least, if there is a direct spec violation that breaks all kinds of
applications and the answer your hear is "oh well, we're working on giving the
user more options and improving our algorithm", that's not exactly
encouraging.

~~~
bullman
It _is_ a direct spec violation, and it _is_ breaking all kinds of
applications.

Look, I get that this capability is _super_ useful on shopping sites, and I
rely on it practically every day.

But, I also build enterprise applications, where Chrome simply _would not
ever_ understand or know what would be valid choice.

I do, though; I built it. Invoice Numbers / Pre-Validated Travel Dates &
Locations / Pre-Validated Locations / Pre-Validated IssueID that are so
esoteric, we have built custom autocomplete that provide additional relevant
information / Pre-Validated Users where the number of valid "John Smith"s
number in the 10s, and additional meta data _must_ be provided to
differentiate.

Application developers need a reliable, durable way to tell the UA that a
particular field should never be autofilled or autocompleted. The spec says
this is autocomplete=off. Just do that.

------
tannhaeuser
It's odd that the linked bug report references and complains about W3C specs
when browser/HTML specs have been coming from WHATWG for well over ten years
now. W3C has ceased publishing HTML with W3C HTML 5.2 in 2017, and has
announced an intent to merely publish WHATWG snapshots going forward; so far,
I'm not aware of any actual work under this model by W3C.

But OTOH that Chromium interprets form field names heuristically to enable
auto-autocomplete is worrying, and reflects poorly on the whole
"standardization" process by WHATWG.

~~~
Santosh83
Indeed. Chrome and Firefox both autocomplete my user name and password into
GitHub's new user registration form, even though I already have an account.
It's flaky and just asking to be abused.

------
duxup
It's really frustrating to have to work around this with hit or miss hidden
inputs and such.

So many cases too where auto complete misfires an obliterated forms that had
helpful placeholder text.

Just having a user change passwords and auto complete will often put an old
saved password in the first field but not the second confirmation password
field.

~~~
johneth
> Just having a user change passwords and auto complete will often put an old
> saved password in the first field but not the second confirmation password
> field.

You can hint to the browser which password you want to autofill with
autocomplete="current-password" and autocomplete="new-password"

~~~
duxup
I've found that auto complete still sometimes guesses at what to do in that
case depending on what the other fields are. At least it did last time I
fought with it.

------
Hokusai
I do not get from where it comes that it is a rogue developer. I have worked
in many companies where developers make mistakes. And, it is always the ways
of working, giving more priority to features than quality, and similar
cultural attributes of the company at fault.

The only time I saw this being a rogue developer was a commit and run done by
a guy on his last day.

It is easy to blame one person when actually is a systemic failure that needs
to be addressed at the company level.

~~~
londons_explore
I agree - and in fact, I think accusing this guy of being rogue is an
unnecessary direct attack on him/her.

They are just doing their job, and in this case, acting in what they believe
is best way for users. Here on HN, it seems most disagree, but that is still
no reason to accuse someone of being rogue.

Headline should be "Google Chrome actively ignores HTML5 standard"

~~~
jefftk
The standard says "SHOULD", not "MUST".

(Disclosure: I work for Google)

~~~
bullman
Where is this supposed "should"?

From the spec - The autocomplete attribute represents either:

a) autofill expectation mantle

b) autofill anchor mantle

If the input type is "hidden", then it is wearing the "autofill anchor
mantle". _IN ALL OTHER CASES_ (emphasis mine) it wears the "autofill
expectation mantle"

And what are the rules on "autofill expectation mantle"?

"When wearing the autofill expectation mantle, the autocomplete attribute, if
specified, must have a value that is an ordered set of space-separated tokens
consisting of either a single token that is an ASCII case-insensitive match
for the string "off", or a single token that is an ASCII case-insensitive
match for the string "on", or autofill detail tokens

...

The "off" keyword indicates either that the control's input data is
particularly sensitive (for example the activation code for a nuclear weapon);
or that it is a value that will never be reused (for example a one-time-key
for a bank login) and the user will therefore have to explicitly enter the
data each time, instead of being able to rely on the UA to prefill the value
for them; _OR THAT THE DOCUMENT PROVIDES ITS OWN AUTOCOMPLETE MECHANISM AND
DOES NOT WANT THE USER AGENT TO PROVIDE AUTOCOMPLETION VALUES_. (emphasis
mine)"

Per: [https://html.spec.whatwg.org/multipage/form-control-
infrastr...](https://html.spec.whatwg.org/multipage/form-control-
infrastructure.html#autofilling-form-controls:-the-autocomplete-attribute)

~~~
jefftk
The "should" is in the spec's description of how to interpret "off": "When an
element's autofill field name is 'off', the user agent should not remember the
control's data, and should not offer past values to the user."

~~~
bullman
So then the crux of the conflict:

In 4.10.18.7.1...

"The "off" keyword indicates either that the control's input data is
particularly sensitive (for example the activation code for a nuclear weapon);
or that it is a value that will never be reused (for example a one-time-key
for a bank login) and the user will therefore have to explicitly enter the
data each time, instead of being able to rely on the UA to prefill the value
for them; or that the document provides its own autocomplete mechanism and
does not want the user agent to provide autocompletion values."

In 4.10.18.7.2...

"When an element's autofill field name is "off", the user agent should not
remember the control's data, and should not offer past values to the user.

NOTE: In addition, when an element's autofill field name is "off", values are
reset when traversing the history."

@jeffk - Ok, I now understand _where_ you are getting this interpretation.

I think this is a dangerous interpretation (and perhaps it requires altering
the spec to say _must_ ). Again Application developers need a reliable,
durable way to tell the UA that a particular field should never be autofilled
or autocompleted. How else do you propose we do that, other than following
4.10.18.7.1.

~~~
jefftk
My parent was saying Chrome was not compliant with the spec, but SHOULD
directives are not mandatory and a User Agent may decide that it would be a
worse experience for users to follow them.

Chrome is claiming that enough developers have marked fields as
autocomplete=off in user-hostile ways that it shouldn't be respected, while
many people here are making the case that conflicts with site-provided
autocomplete and other issues push the other direction. That's how to have
this discussion, not by pretending this SHOULD is a MUST.

(I don't work on Chrome and don't know any Google-internal anything about
this)

------
speedplane
I run a site with a normal login/password, but which maintains passwords for
other systems. It's pretty frustrating when the internal external usernames
are autofilled with the username from our site. It confuses the user,
suggesting that the username from the external site should be the same as our
own.

------
PerfectElement
I was using Google Places' address auto-complete on a CRM, and most users
loved it. Chrome's behavior completely broke this functionality by overlaying
their auto-fill on top of Google Places suggestions, with no sane way to
disable it. We decided to stop using address auto-complete and force our
customers to type the address fields instead.

Ironically, we were paying Google a few thousand dollars per month for this,
so they are not getting our revenue as a direct consequence of Chrome's
behavior.

------
dazbradbury
I'm not sure who Chrome think they're helping. We get many, many users
contacting our support team because of this feature / bug on
[https://www.openrent.co.uk](https://www.openrent.co.uk).

It's frustrating, we've used workarounds, which then stop working and reports
come flooding in again. It's crazy to me that the Chrome team think this is
better for users, and that there isn't a more intelligent workaround for sites
abusing autocomplete=off.

~~~
vidarh
At some point the alternative will be to implement a custom input control,
which will just be awful in all kinds of ways, but it's just as awful to have
Chrome think it knows best in some contexts.

------
andrewstuart
The Chrome dev team have implemented autocomplete the way they think it should
work, not the way web developers want.

You cannot switch off Chrome's handling of autocomplete, thus any other
autocomplete implementation will be overwritten by Chrome's handling.

Chrome team feel they know best.

~~~
chris_wot
They are becoming the Gnome of browsers. The Chrome dev team seem to be
getting more and more user hostile.

~~~
nordsieck
> They are becoming the Gnome of browsers.

What they're becoming is ie6.

------
tus88
I would love it if someone explained how 'autocomplete=off' can lead to abuse
of some kind. It seems to reduce the potential for security leaks.

~~~
pilif
It causes spec-compliant password managers to not work.

Unfortunately, disabling autocomplete for password fields is an often used
form of security-theatre

~~~
tmd83
Here's the tricky thing and I don't have a solution that doesn't get abused. I
hate that lots of bank do this but I also have a use case for password
autocomplete=off. We operate in an industry where shared computer access is
very common and the risk of users saving password in browser is real and too
high.

As I said don't know what the answer is. I definitely want someone using
password manager be able to use them. Using a password manager is a conscious
choice with setups involved. Browser's default autocomplete is often not. I
don't know how to separate these two out.

~~~
epochwolf
Isn’t it on the people administering those systems to disable autofill on
their side?

~~~
tmd83
In theory it is. But for most customers (who are small) there's almost no IT
department and the average computer literacy is lower than you might think
(though improving) so the risk is there. Except for that situation I would
happily leave them autofill/save password.

------
avodonosov
Bad that chrome developers don't practice web development enough to know the
use cases where ignoring autocomplete=off breaks the application.

------
mgoetzke
Or line of business applications which (when rendered with Chrome) wants me to
pick from my credit cards when I enter a certain field which has nothing to do
with credit cards. I think it depends on the field name, but there seems to be
a very loose correlation.

------
needle0
Another reason to abandon ship and switch to Firefox.

------
avellable
With the new direction chrome is going I wouldn't mind putting "works best on
anything but Chrome" on my next web project.

~~~
dustinmoris
I was thinking the same, websites should just have a big popup somewhere
saying that the website might not work on Google Chrome, because it is W3C
compliant and Google Chrome doesn't implement W3C standards, whith links to
download alternatives browsers.

~~~
vntok
Please go read the spec, you will find that Chrome is perfectly compliant with
it regarding the autocomplete attribute handling.

------
dang
The submitted title was heavily editorialized:

"Rogue Chromium dev lead ignores W3C 'autocomplete' spec; frustrates Internet"

------
lowercased
> This causes some problems, e.g. in <input type="text" name="name">, the
> "name" can refer to different concepts (a person's name or the name of a
> spare part).

Maybe I need context, but I don't understand why they're trying to 'guess'
context around 'name' and trying to autofill something - either a spare part
or a person's name.

Doesn't "name='name'" indicate that it should refill with the previously
filled value of field named 'named' on that same page/document/url? Why are
they trying to add algorithmic complexity on to already existing stuff?

<input --chrome-type="name"/>

This might make more sense, no? Let chrome try to determine a 'name' based on
whatever logic they want.

------
velox_io
There's a major security flaw with auto-fill when it comes to passwords. Sure,
it's hidden on screen, but you only have to change the password box's type, so
it isn't "type='password'" and it is revealed. This only takes a matter of
seconds.

Chrome should remove the password if there is any attempt to change that form
object.

This flaw has been there for years, it's actually handy if I'm not sure what
the password is.

~~~
Smithalicious
Is this really an issue? Presumably anyone with access to the browser can
acces saved passwords anyways; the censoring only prevents onlookers from
reading it.

~~~
Avamander
Actually on Windows at least Chrome asks for a password when trying to view
all passwords. So it isn't _that_ easy.

------
user5994461
>>> \- How to trigger the hiding? - right mouse button menu or (more likely)
something in the drop down? where would we put that? ...

Mobiles notoriously don't have mouse buttons, so any UI relying on right-click
will not be usable there.

It's odd that Google is considering mouse-based workarounds in all considered
solutions, as if unaware of that. or maybe Chromium is only the desktop
browser?

------
packetized
This position seems at odds with a recently opened WHATWG issue.

[https://github.com/whatwg/html/issues/4986](https://github.com/whatwg/html/issues/4986)

------
codegladiator
> if you add an <input type="hidden" autocomplete="username"
> name="does_not_matter" value="{the actual username}"> before your current-
> password and new-password fields, Chrome should get it right

I can't believe that this suggested hack is coming from google.

[https://bugs.chromium.org/p/chromium/issues/detail?id=914451...](https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c63)

------
platz
> Comment 66 by battre@google.com on Tue, Oct 8, 2019, 3:48 AM CDT (5 days
> ago) \- Overall, I still believe that neither of the extreme strategies
> ("always honor autocomplete=off" and "never honor autocomplete=off") are
> good

[https://bugs.chromium.org/p/chromium/issues/detail?id=914451...](https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c66)

We're in for the Long haul on this one.

------
tyingq
Discussion about a demo of the issue...

[https://news.ycombinator.com/item?id=13329525](https://news.ycombinator.com/item?id=13329525)

------
marcoseliziario
If you look at the chrome sources you can find this flag:

const char kAutofillOffNoServerDataDescription[] = "Disables Autofill for
fields with autocomplete off that have no " "crowd-sourced evidence that
Autofill would be helpful.";

So, at least in a company, this should work to avoid autocomplete making
corporate apps unusable.

another thing that seems to work for me, is adding role="combobox" along with
autocomplete="off"

------
tehabe
I guess this bug is the real reason why I turned off auto-fill in the browser
a while ago, because it acted weird a lot of times.

------
marcoseliziario
So far this combinations seems to be working for me

role="combobox" autocomplete="off"

------
asdf-asdf-asdf
title is wrong, the spec is not ignored. spec says: " When an element’s
autofill field name is "off", the user agent should not remember the control’s
data, and should not offer past values to the user. "

please note that it uses "should", not "must". these words have precise
definition in specs, see RFC2119:

" SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist
valid reasons in particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before choosing a
different course. "

one may argue whether chrome has valid reasons or not, but saying they ignore
it is incorrect.

~~~
mstade
> [...] there may exist valid reasons in _particular_ circumstances [...]

(Emphasis mine.)

Is it really spec compliant when the "particular" circumstance is all of them?

------
chris_wot
Previously closed as WONTFIX:
[https://bugs.chromium.org/p/chromium/issues/detail?id=468153](https://bugs.chromium.org/p/chromium/issues/detail?id=468153)

~~~
chris_wot
Later they filed:

[https://bugs.chromium.org/p/chromium/issues/detail?id=587466](https://bugs.chromium.org/p/chromium/issues/detail?id=587466)

------
onion2k
Does Chromium not have anyone doing QA or acceptance criteria? A rogue dev
lead could make whatever feature they want, but there should be a robust
process of testing by many people before the feature makes it in to a
production build.

------
aiCeivi9
I hat to fight with browser autocomplete in Kibana main search bar. On the
other hand I guess it is the same as right mouse button - I don't allow any
site to capture that event since some abuse it.

------
dannykwells
A rare example where an editorialized HN post title is appreciated. Bravo!

------
sm4rk0
Just stop using Chrome. There are good (even better) alternatives.

------
edoceo
I use autocomplete="x" and it seems to work for my apps.

Both Twilio and NameCheap seem to have login that defeat autocomplete in a
nice way. Haven't investigate their tricks

------
mfer
> This has turned into a sad tit-for-tat between developers and Chrome, where
> no-one is winning.

Not the kind of relationship you want to build with an army of advocates

------
enriquto
I love the edited title of this post. It reflects accurately the reality of
the situation. Hey, battre, hi there! You are famous now!

------
robotstate
I wrote a Medium article on how to actually turn it off 3 years ago that
consistently gets about 500 views a week to this day.

------
phendrenad2
I wonder what kind of engine overhaul Chrome is doing to cause all of these
strange breakages.

------
smashah
This also screws with notion to the point where I've largely stopped using it
at all

------
iandanforth
We're Google, we don't have to respect the spec.

------
wolco
As a developer this can be fixed by using unique field names.

------
imode
Is "ignoring the specification" an extreme, now?

Are we seriously expected to entertain this mess?

So glad I switched to Firefox all those years ago.

~~~
dustinmoris
Google slaves came to downvote you after someone said this on their internal
chat lol.

------
bullman
There was a time when IE was the dominant browser, and happily did whatever
they wanted to.

That was arguably better, because at least they acted predictably. Chrome has
been continually altering how autocomplete is handled in the last 5 or 6 major
releases

~~~
IshKebab
They acted predictably by never updating IE and letting it stagnate. Hard to
see how that is better in any meaningful way.

~~~
pjmlp
You still had a choice, nowadays being a Web Developer is almost a synonym for
Chrome Developer and it was the IE hatting crowd that made it happen.

~~~
yoz-y
Except Chrome is still far below the user-base of IE in its heyday. And the
most "valuable" users are all on mobile Safari. So it still makes sense to at
least test with that.

~~~
capableweb
"the most "valuable" users are all on mobile Safari"

Not at all, as only 20% of the people using mobile browsers at all, are using
Safari.

~~~
The_rationalist
To be accurate: Safari has 20% of mobile browser marketshare. And 5% of
desktop browser marketshare. So globally they are <20%

------
platypii
Thank you chrome, for recognizing that the USER is what matters, not the
website developer. Websites started blocking legitimate uses of autocomplete,
and that makes the web less secure. As a user I sincerely hope that
"autocomplete=off" dies just like the blink tag, as it is user hostile.

