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

Safari tries to fill username

github.com

Post reply on HN
Print view View original

61–70 of 393 posts

Re: Safari tries to fill username

#61

Post by HatchedLake721 »

realusername wrote: post #8
HatchedLake721 wrote: post #4

Earlier quoted context omitted.

Such as?

Like SVG background issues https://stackoverflow.com/questions/40986798/repeated-svg-ba... clicking issues https://stackoverflow.com/questions/24077725/mobile-safari-s... (yeah even clicks are broken) background jank https://stackoverflow.com/questions/9983520/webkit-animation... (not sure it's exactly this bug but I do have fixes in the codebase for that) round corners https://stackoverflow.com/questions/50995411/ca…

And these are "total nonsense" for you?

- SVG background issue from 2016. Tested on my Safari Tech Preview 113 (Sep 2020), can't replicate.

- Clicking issue. This is related to mouse event bubbling on iOS only (will affect both Safari and Chrome since they both use the same WebView). It's theorised that Apple set a specific set of rules when mouse events (on touch devices) will bubble up for performance/usability. Or it's just a bug.

- A rendering issue from 2012. It's explained in your link this is related to pre iOS 7 era performance improvement by WebKit to only redraw those parts of an image that have changed. Sounds like a very reasonable thing to do, taking into account how Apple heavily pushed performance and battery savings on mobile/laptop devices a decade ago.

- Round Corners. Tested on my Safari Tech Preview 113 (Sep 2020), can't replicate.

I don't see how any of these are anywhere close to being "total nonsense", feels like you're being biased and just exaggerating on purpose to bash Safari.

Chrome force logging in you when you use Gmail to hijack your privacy and link your browser history to an account sounds more "nonsense" than Apple focusing on performance/battery on mobile devices a decade ago that created a regression/new bug that requires 1 line to solve. https://news.ycombinator.com/item?id=17942252

I primarily use Safari for privacy/battery/performance reasons, and on my web app of 2 years with tons of styling I have 5 lines of scss code with "// safari" comment to make some elements render the same as Chrome.

Never in my career writing a single digit line of additional css made me think "oh my god this is total nonsense". Everyone has to accept there will be differences from one browser engine to another, and from my personal experience, these are minimal and nowhere near IE6 back in the days.

Re: Safari tries to fill username

#62

Post by izacus »

airza wrote: post #43
WayToDoor wrote: post #7

Related, there is a "bug" in chrome that disabled autocomplete="off" on input elements, marked as won't fix https://bugs.chromium.org/p/chromium/issues/detail?id=587466

The nuance here is that brain-damaged appsec pentesters reported this as a vulnerability for years, and so tons of websites followed that advice and dutifully disabled the functionality. But autocomplete has advantages: it lets users easily specify long, random, per-site passwords without ever having to worry about that. And when they can't do that, a pretty large percentage of them just give up and write the passwor…

Oh man, enterprise "security" firms used by banks and other old behemoths are a cancer for users. If you want your website to actively abuse users (especially one with special needs and pretty much anyone that doesn't fit into an "made up average person mold") get those people on board and listen to the dumb things they say.

I still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST use SMS for 2FA!".

Re: Safari tries to fill username

#64

Post by rimliu »

rashil2000 wrote: post #17
rimliu wrote: post #11

Earlier quoted context omitted.

There is a browser without bugs?

No, but Safari routinely causes many problems that seem utterly basic for Firefox/Chrome.

Because you develop on Chrome, and only occasionally test on Safari. Try the other way around and see which one is buggy.

Re: Safari tries to fill username

#65

Post by rimliu »

bryanrasmussen wrote: post #25
rimliu wrote: post #11

Earlier quoted context omitted.

There is a browser without bugs?

so - is this your defense of IE11 as well? There are several questions regarding bugs - how many are there, how difficult are they to find, how difficult are they to fix. It seems that there are many Safari bugs that are difficult to find, and to fix, which makes them worse than other browsers. In this case I believe the bug is actually difficult to find, this guy found it but I bet a lot of developers just went and…

I am not defending anything. Just wondering. I have literally decades of the web dev experience, I had to do pixel perfect CSS layouts for IE5. These comparisons are stupid beyond belief.

Re: Safari tries to fill username

#66

Post by emilfihlman »

orangepanda wrote: post #51
Lex-2008 wrote: post #49

Earlier quoted context omitted.

OTP one-time-password fields

autocomplete="one-time-code" Any others?

Chrome recommends wrong passwords, passwords from wrong subdomains, and passwords for pages that will never accept custom passwords.

It's broken as fuck.

Re: Safari tries to fill username

#68

Post by jpttsn »

thomasfortes wrote: post #48
eitland wrote: post #35

Earlier quoted context omitted.

No. This is a small but important detail: Chrome is the new IE. IE wasn't mainly a problem because it didn't support things, rather because it was - in the beginning - superior, but also had all sorts of non standard behaviour that Microsoft pushed and that made competition crazy hard. Oh, and also because they pushed it relentlessly in all ways including - as was later confirmed in court - illegal ways. Exactly like…

Both are the new IE, one push features without caring about the rest of the ecosystem and the other refuses to implement standards without caring about the rest of the ecosystem. The end result is that the web right now has stuff that works only on Chrome and stuff that works everywhere besides Safari. And the fact that iOS users can't change their browser forces developers that want their projects to reach the maxim…

Honest question: Do we have any scroll vs. marquee type situations today?

Because (Unpopular): I believe the standard should primarily cover how the overlapping functionality works, and refrain from limiting or prescribing the extent of functionality.

Comparing: If I build a HTTP API, I don’t have to support the DELETE verb for any endpoints. I can support ENCHANT if I want magic that other servers don’t have. But if I use GET, the endpoint handler should be idempotent. That’s the kind of standard I appreciate.

I don’t see any realistic win-win otherwise. Either you hold Chrome back from implementing new crap, or you force Safari to implement stuff they don’t want to. The efficient number of browser vendors seems to be small, so I think the standard body has just overplayed it’s hand.

Re: Safari tries to fill username

#69

Post by rhdunn »

heinrichhartman wrote: post #56
WayToDoor wrote: post #7

Related, there is a "bug" in chrome that disabled autocomplete="off" on input elements, marked as won't fix https://bugs.chromium.org/p/chromium/issues/detail?id=587466

I tend to side with Chrome here. IMHO, the decision of whether to show auto-complete should be with the user and not with the website. When I install an auto-complete add-on or activate a browser feature, I expect the AC to be available on ALL input fields, whether the site owner thought that would be a good idea or not. Now, there is a valid question on how the user should be able to configure the AC behavior, and h…

The problem is when the web browser gets it wrong and decides to show autocomplete for an unrelated field, or a field that is not a login/enter password page. Some examples I've had to deal with:

1. A "name" field on a dialog for creating values in a controlled vocabulary (e.g. genres in fiction) -- Chrome thinks this is a username field so brings up a user autocomplete. I guess it thinks that "Jane Smith" is a valid label!

2. Editing user details (username, full name, email, etc.) -- Firefox thinks the email is a good place to autocomplete the password.

With these, I've had to employ several workarounds to tell the web browsers that these are not login forms, so please don't autocomplete them as such, all because they ignore `autocomplete="off"`. I've got these working now, but if Chrome/Firefox decide to ignore the markup because of sites misusing them (like they've done before), I'll need to work out how to avoid this again.

Re: Safari tries to fill username

#70

Post by thaumasiotes »

izacus wrote: post #62
airza wrote: post #43

Earlier quoted context omitted.

The nuance here is that brain-damaged appsec pentesters reported this as a vulnerability for years, and so tons of websites followed that advice and dutifully disabled the functionality. But autocomplete has advantages: it lets users easily specify long, random, per-site passwords without ever having to worry about that. And when they can't do that, a pretty large percentage of them just give up and write the passwor…

Oh man, enterprise "security" firms used by banks and other old behemoths are a cancer for users. If you want your website to actively abuse users (especially one with special needs and pretty much anyone that doesn't fit into an "made up average person mold") get those people on board and listen to the dumb things they say. I still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST…

> I still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST use SMS for 2FA!".

Weeeeeelll...

I'm familiar with two (2) common kinds of "2FA" implementations. TOTP and SMS.

Of those two, only SMS is actually a second factor, albeit not a particularly secure one. TOTP is fundamentally a password, and two passwords are no different than one password.

Post reply on HN