Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Issue 914451: Autofill does not respect autocomplete="off"

bugs.chromium.org

Post reply on HN
Print view View original

241–250 of 383 posts

Re: Issue 914451: Autofill does not respect autocomplete="off"

#241

Post by phyzome »

atVelocet wrote: post #238
carstenhag wrote: post #41

As I had already commented on the issue, it completely breaks Germany's main train ticket selling website: 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.chro…

Finally i know why this happens only in Chromium. This irritates me for quite some time now... Seems that Chromium based browsers aren't favorable any more: Tracking, Bugs, uBlock extension is flagged, Manifestv3, etc. But Firefox has the same problem since it ships with Pocket and other sync stuff. I know that they really do care but they have problems of their own which really make me think which browser to use. Th…

Pocket and sync are opt-in and seem pretty tame compared to the stuff in Chrome, just saying...

Re: Issue 914451: Autofill does not respect autocomplete="off"

#242

Post by danso »

rc_mob wrote: post #239
sandstrom wrote: post #106

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-... ## Example 1 For a reliable workaround, you can add this cod…

I still don’t understand why any self respecting developer would use Chrome. I understand why your grandma or parents would use Chrome. But I just cannot compute how a knowledgeable developer would install Chrome.

Because Chrome has 70% of the global market share, and web developers should know what their customers use?

Re: Issue 914451: Autofill does not respect autocomplete="off"

#243

Post by atroche »

jvolkman wrote: post #232
eli wrote: post #226

Earlier quoted context omitted.

When a phrase is used the “wrong” way more often than the right way, it ceases to be wrong.

What about "I could care less"? Seems like that one is just always wrong.

Thinking about language usage as "wrong" or "right" might not be the most helpful way to think about it: https://stancarey.wordpress.com/2010/02/16/descriptivism-vs-...

(p.s. not saying there's no wrong or right when it comes to ideas themselves)

Re: Issue 914451: Autofill does not respect autocomplete="off"

#244

Post by notatoad »

EugeneOZ wrote: post #160
sandstrom wrote: post #106

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-... ## Example 1 For a reliable workaround, you can add this cod…

I haven't tried it, but maybe div with "contenteditable" could help?

This is what I resorted to on one of our internal tools that wants a phone number to be entered and kept getting auto-completed with our staff'S phone numbers.

I wouldn't recommend it for public use. There's a lot of subtle behaviour around an input field that you'd need to replicate manually.

Re: Issue 914451: Autofill does not respect autocomplete="off"

#245

Post by erichurkman »

klmr wrote: post #181
watwut wrote: post #82

Earlier quoted context omitted.

Imo, valid use case for autocomplete=off is "the developer of webapp wants it". Literally that and nothing more.

Unfortunately a few developers are morons who misuse features, and browser vendors try hard to work around them. Case in point, lots of websites used to put `autocomplete="off"` on password boxes, which breaks some password managers. IIRC that’s why Chrome (and other browsers) decided to sometimes ignore the `autocomplete` attribute in the first place. Of course that doesn’t justify ignoring it completely (just for p…

Now they need to ban intercepting/blocking `onpaste` in form fields.

Re: Issue 914451: Autofill does not respect autocomplete="off"

#246

Post by onli »

scient wrote: post #223
onli wrote: post #197

Earlier quoted context omitted.

Exactly. Autocomplete=off gets misused. For example, there was a browsergame I played where because of idiotic "security considerations" autocomplete=off got applied to the login screen. At that time for me that meant typing in the password manually, thus picking a bad password. So it's a good thing in that situation when the browser ignores the attribute.

Very egoistic and ignorant way of viewing things. Disabling autocomplete on login screens has its uses, especially on any app that has shared-terminal type of use, where you cannot trust the user to make the smart choice of not remembering their password - or evening exposing the previous users emails that were used. You picking a bad password has nothing to do with this feature.

No, it does not have its uses in those scenarios. Every website with login could be used in such a scenario, in an internet cafe for example. It's not on the web developer to predict this, it's on the terminal to prevent that issue.

It has its uses in some very limited scenarios, like a password field in a blog editor that when set locks the article for users not knowing the password. But that's not a login screen.

Me picking a bad password was absolutely caused by this misuse of autocomplete=off, it had everything to do with it. How can you claim otherwise? I was there, you were not.

Re: Issue 914451: Autofill does not respect autocomplete="off"

#248

Post by notatoad »

azernik wrote: post #29

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 w…

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.

Re: Issue 914451: Autofill does not respect autocomplete="off"

#249

Post by Nitramp »

sky_rw wrote: post #98
Nitramp wrote: post #94

Earlier quoted context omitted.

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.

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 ne…

> Nobody here is arguing that.

Well, OP that I responded to literally argued that.

I agree the platform needs to expose useful features in a predictable manner for application developers.

But I'd much rather have browsers decide what's reasonable control over the user experience.

Re: Issue 914451: Autofill does not respect autocomplete="off"

#250

Post by meredydd »

dmix wrote: post #113
VMG wrote: post #46

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

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 me…

If you think late rendering or "display:none" will put Chrome off, think again! The anvil.works IDE is Angular, so it's all rendered post-loading, and Chrome still autofills the weirdest things. Relentlessly.

Search boxes? Sure! App titles? Yeah, one week a bunch of our users' apps got renamed to the author's email address.

Being an IDE, of course, there are lots of places where inserting random text will break things. When I open up the console and see it filled with "'meredydd@anvil.works' is not a valid Python identifier"? That's the signal to go hunting for which dynamically-generated off-screen text box Chrome is stuffing credentials into this week.

TL;DR Chrome's autofill is out there. It can't be bargained with. It can't be reasoned with. It does not feel pity or remorse. And it will not stop.

Post reply on HN