8 ms·
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/
by carstenhag 7y ago
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 7y agoImo, valid use case for autocomplete=off is "the developer of webapp wants it". Literally that and nothing more.
- Nitramp 7y agoIt'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 7y agoDismissing 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.
- deleted 7y ago[deleted]
- TeMPOraL 7y agoThe 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 7y agoIn this case, it can be overridden by the user, just not the developer :)
- xg15 7y agoNot really if the user is non-technical and doesn't even know they'd have to override it.
- basch 7y ago"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 7y agoI 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.
- Vinnl 7y agoGP 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 https://news.ycombinator.com/item?id=21239172
- watwut 7y agoShould developer be able to make it impossible to close browser or open 100 new tabs? No. Should developer decide that fields are autocomplete off or green or show javascript warnings? Absolutely yes. If user wish to change that, users thing. The browser/google has no business to be mediator here, second guess application they know nothing about and manipulate it. The browser should be predictable, well specified and harmless. It should not force me to convert all ids into random strings just so that random data do not get prefilled in.
- michaelt 7y agoI've heard plenty of people on HN say password managers should ignore autocomplete=off and I agree with them. Because that setting is mostly applied by organisations like banks who incorrectly think they're making things more secure by doing so. IMHO there are cases where autocomplete=off should be respected, and other times when it shouldn't be - it's certainly not as simple as saying always do or always don't respect it.
- kalleboo 7y agoPassword managers should ignore autocomplete=off in login screens, but not in administration screens where you’re editing other people’s credentials. IMO the distinction could be made to not automatically fill when the autocomplete=off but instead add a button to let the user initiate it
- rhizome 7y ago
- Nitramp 7y ago> 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.
- watwut 7y agoIf the user installs extension to auto fill everything, it is on him. When the browser decided to ignore spec, it is not user agency at all. The need for auto fill is extremely application specific and the action is quite often destructive. And it is developer who gets to be blamed for lost data.
- sneak 7y agoHow do I install extensions into my most commonly used browser (my phone)?
- andrewshadura 7y agoStart using Firefox on your phone.
- Lammy 7y ago(on Android)
- Hamuko 7y agoBut I'm developing the application for the users. It's pretty annoying that we have to make hacks for a client card page not to automatically assume you want to fill in your own details.
- codedokode 7y agoThen ask the user before filling anything.
- chaboud 7y agoThat's a bit of an appeal to extremes. Visually rendering static HTML per the spec is a situation where a browser "just followed developer's whims", and it's why protocols and standards exist. That a browser could reliably infer from context what the right information to insert into a field could be is one of those things that gives great demo and may even work more often than not, but it's a virtually impossible problem to solve comprehensively. Developers have plenty of valid reasons to disable autocomplete and autofill functionality. Taking that away from them and requiring an obfuscating workaround is tantamount to creating an invisible pseudo-standard. Imagine what would happen if we decided to solve the scourge of signed-unsigned pointer value bugs in C++ by having the compiler virally assume unsigned variable typing for memory related operations based on variable name. It might feel like a quick fix to a widespread problem, but it would break down all over the place and would break the code of developers who A) followed the spec B) knew what they were doing and C), at least some of the time, were doing it for a specific purpose. These sorts of changes remove the incentive to write standards compliant code, leading to a mangled universe of hacks, quirks, and, in the end, bugs.
- dreamcompiler 7y agoAnd e.g. disabling Paste. But it seems clear that autocomplete gets it wrong often enough that developers should have some say in the matter.
- ckrailo 7y agoBrowsers already follow developer whims, see: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Fe... YouTubeTV uses feature policy to disable the browser's picture-in-picture feature.
- Rexxar 7y agoIt's the same meaning but I would prefer "just follow the specification an let developer decide what they want"
- klmr 7y agoUnfortunately 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 password fields) but maybe a similar reason is at play.
- onli 7y agoExactly. 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.
- scient 7y agoVery 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.
- onli 7y agoNo, 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.
- TurningCanadian 7y ago
- wdr1 7y agoWhat if the user doesn't?
- obituary_latte 7y agoOT: direct link bypassing imgur’s horribly hostile UX https://i.imgur.com/BjYTgSn_d.jpg?maxwidth=1640&shape=&fidelity=high https://i.imgur.com/BjYTgSn_d.jpg?maxwidth=1640&shape=&fidel...
- lqet 7y agoCan anyone explain why the same behavior does not occur on https://www.sbb.ch/ 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.
- subroutine 7y agoDid 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 https://i.imgur.com/NlzVqhT.png and here's what it looks like when I enter 's': https://i.imgur.com/1u4Iy7S.png https://i.imgur.com/1u4Iy7S.png (actually, S does not autocomplete in the Swiss site)
- lqet 7y agoYou 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...
- subroutine 7y agoI think it might have that behavior because they have the auto-complete tag set to... <input id="fromField" type="text" inputmode="text" class="mod_textfield_control" placeholder="Von" autocomplete="new-password"... Though, there is also a lot of other stuff going on in that html element I don't understand.
- masklinn 7y agoThat's an interesting hack as autocomplete=new-password will generally disable autocomplete. Though it may not work every time, as browsers & password managers might also suggest new passwords (following whatever their internal generation rules are).
- LoSboccacc 7y ago
- atVelocet 7y agoFinally 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. The actual situation right now is very frustrating...
- phyzome 7y agoPocket and sync are opt-in and seem pretty tame compared to the stuff in Chrome, just saying...
- breakingcups 7y agoI use Firefox as my main browser on all my machines and haven't once been bothered about Pocket or other sync stuff. I vastly prefer it, for moral and technical reasons. I feared the switch from Chrome would be very hard and aggravating but it wasn't. (The only thing that got me the first few weeks is that opening an incognito window is ctrl+shift+p instead of ctrl+shift+n. Once I got used to that I realized it actually makes sense because ctrl+shift+n re-opens a closed window just like ctrl+shift+t reopens a closed tab.)
- ulucs 7y agoctrl+shift+p feels more natural to me as Forefox calls it "Private Browsing" whereas Incognito doesn't even start with a n
- jvzr 7y ago(Firefox user here) I find that ctrl+shift+n makes more sense: ctrl+n for a new window, add shift for a modified (incognito) new window. Although whichever shortcut is a very quick habit change to make anyway
- takeda 7y agoI'm guessing chrome ignores, it because people often place the option when they shouldn't. I don't understand why browsers can't simply respect setting and perhaps provide option for the user to modify behavior per site per field with ability to save. They could go even step further and do what Opera used to do i.e. provide same defaults for most popular sites.
- jmkni 7y agoI had this issue the other day, I solved it by generating a GUID each time the page loads and appending it onto the end of the ID. Not ideal, but worked!
- lone_haxx0r 7y agoIn general, I don't like software defaulting to convoluted "grandpa-friendly" behavior instead of the simple, no-bullshit behavior. Moreover, if you want the simple, sane behavior you're a weirdo and need to justify yourself. Another example of this is chrome hiding "trivial" parts of the URL. i.e. any subdomain that coincides with "www" or "m".