Live data from Hacker News

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

bugs.chromium.org

121–130 of 383 posts

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

#121
post #101
post #87

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

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

Point taken. Maybe in this case the spec authors were also at fault for leaving too much leeway in the implementation.

Nevertheless, from their stance on the issue so far it stands to reason that the Chromium team would have objected to any efforts to tighten the spec, which would also have led us to this same situation.

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

#122
post #101

Earlier quoted context omitted.

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

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

Well, that's what Chrome always does? Just like the preventDefault breaking change thing. They have no problem ignoring developers if they think it will be a net benefit for user experience.

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

#123

Earlier quoted context omitted.

That is a thing already! https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

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.

Really?

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

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

#124
post #98
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…

GP is explicitly not dismissing the above use cases, but merely the supposed justification of "the developer wants it" being enough.

> 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.

GGP was literally arguing that: https://news.ycombinator.com/item?id=21239172

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

#125

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

> [...] there may exist valid reasons in particular circumstances [...]

(Emphasis mine.)

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

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

#126
post #87

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

It’s heresy on HN to suggest that a single browser running the web is a bad idea.

HN comments pretty consistently argue that browser monoculture is a problem. I don't know where you're getting this.

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

#127
post #111

Earlier quoted context omitted.

Can anyone explain why the same behavior does not occur on https://www.sbb.ch/ , the Swiss equivalent (which is based on the same software by HaCon)? E: as soon as you submit a search on sbb.ch, the same problem occurs.

Did you try using a first-letter of a location you commonly use in forms? Here is what mine looks like when I use 'm' (like OP): https://i.imgur.com/NlzVqhT.png and here's what it looks like when I enter 's': https://i.imgur.com/1u4Iy7S.png (actually, S does not autocomplete in the Swiss site)

You are correct! As soon as I submit a search query on sbb.ch, the same problem occurs with that query.

I always concluded that it was the fault of the website creators. Guess I have to switch to Firefox...

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

#130
post #98

Earlier quoted context omitted.

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…

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.

In this case, it can be overridden by the user, just not the developer :)
Post reply on HN