Live data from Hacker News

Chrome breaks the Web

tonsky.me

461–470 of 473 posts

Re: Chrome breaks the Web

#461

Earlier quoted context omitted.

Either googles solution is better or its not. If it is then google should make it the default even if it provides an option. Then even if they provide the option 99.999% will use the default rendering the option basically worthless. If its not they should probably just work how everyone else works.

If you use that approach on everything then you admittedly get clean and easy to understand configuration, but you also reduce the usefulness of your app and make some of your regular users very unhappy... I stopped using Ubuntu recently for exactly that reason, too many options were cut and hidden away from GUI, and just defaults enforced on you, to the point that Windows Explorer is now far more powerful and custom…

Nautilus is not exactly a power tool. Personally I rather enjoy spacefm.

Its super trivial to bind hotkeys to shell functions that operate on the current directory or files or whatever. I know that some of this can be done with custom actions but its nice to be able to a) bind keys not just provide a context menu item and b) create a custom command with a few clicks.

Example something like autojump or what have you is a common tool for shell users. Its nice to bind a key to pop up a prompt key in a string and have this jump to a directory in your file manager using the same source of info as autojump.

This took like 30 seconds to figure out and set up.

Another example a hotkey show a thumbnail gallery of every image recursively below current dir.

Re: Chrome breaks the Web

#462
post #9

> they made all top-level event listeners passive by default. They call it “an intervention”. This is my very problem with Chrome/Chromium right now. The Chrome team does assumption on how things "should" be (in a highly subjective way) and breaks the web. Another example: they decided to ignore the value of `autocomplete` attributes on ` ` tags [1], because: > The tricky part here is that somewhere along the journey…

And, unless this has been fixed (does anybody know?) ..

Autocomplete is a security problem that can be used to get more information from users than they think they are providing - just ask for one field like email but put the other fields to be auto completed as hidden, and the browser helpfully gives the site all the other fields the user didn't realise are being autocompleted..

Re: Chrome breaks the Web

#463
post #287

Earlier quoted context omitted.

With evergreen browsers, that basically requires a dev team to adjust the code and release/deploy a new version every X months. WHICH IS OKAY, if we're talking about security/privacy, but performance ... not really. Let the market (and the users) decide. If a site takes forever to load, and scrolling is impossible because it takes ages to scroll, and burns a mark in your palm in that time, then maybe you'll reconside…

With evergreen browsers, that basically requires a dev team to adjust the code and release/deploy a new version every X months. WHICH IS OKAY, if we're talking about security/privacy, but performance ... not really. It's not automatically OK to break functionality even for security/privacy reasons, IMHO. Browsers are used for many useful purposes that do not involve visiting sites run by large organisations with full…

Static sites without maintenance are not a problem, they remained readable all these years, and I guess they'll continue to be so. (ACID test and all.)

And there are non evergreen browsers for those environments.

I agree that unilateral moves are bad for the web, but the reality was always that. Vendors have their own agendas, and usually the overlap is large enough.

Plus the change was always there too. Framesets work just as 'fine' today as they did back in '96, and the same goes for tables, divs, and falling snowflakes in the background DHTML snippets. The churn we see today is because the web became a lot more diverse, a lot of things were and are still live on the edge, some are in terms of performance and creative expression (just think about CSS Houdini, giving even lower level access gradually to the rendering pipeline), some in terms of security (because they depend on some implementation detail of browsers - such as CSRF protections, that took a decade to get sort of right with the Same Origin policy).

Re: Chrome breaks the Web

#464

Earlier quoted context omitted.

I have a site that deals with HIPPA protected information. I absolutely don’t want autofill, especially for sign in information. Chrome makes that impossible and just ignores the code.

Could you explain the downside of allowing auto-fill for sign-in information here? I understand that security is a concern, but I don't see how allowing a password manager to handle sign-ins would be harmful.

I can't remember exact scenarios that triggered it, but I've seen situations where Chrome autofills data other than sign-in passwords as well (also ignoring autocomplete=off).

There was a form where administrator can change certain details of another user profile, and if e-mail (or name) field was empty on a profile, then chrome would autofill it with administrator's e-mail, which can result in unwanted / corrupted data.

Some replies in this thread suggest configuring chrome differently in organizations where this is important to avoid, but when you are SaaS vendor, your users will inevitably blame you for Chrome's behavior.

Re: Chrome breaks the Web

#465

Earlier quoted context omitted.

> IMO we should be breaking JavaScript more often, especially in the name of performance, to make people use less JS and simpler JS on their websites. Though not by pushing it down people's throats in a backwards-incompatible way.

I don't understand your argument? You seem to agree "we should be breaking JavaScript" but you're against backwards-incompatibility...which is just a way of saying "breaking JavaScript."

I agreed on this part:

> to make people use less JS and simpler JS on their websites

Re: Chrome breaks the Web

#466
post #9

> they made all top-level event listeners passive by default. They call it “an intervention”. This is my very problem with Chrome/Chromium right now. The Chrome team does assumption on how things "should" be (in a highly subjective way) and breaks the web. Another example: they decided to ignore the value of `autocomplete` attributes on ` ` tags [1], because: > The tricky part here is that somewhere along the journey…

but but but, that one guy said that women were different.

you're all idiots.

you deserve this. you deserve worse.

Re: Chrome breaks the Web

#467
post #212

Did anyone's website or web app break because of this change in Chrome 56? I ask because the article lists a couple things that could break such as drag 'n drop but I have not noticed anything breaking in my experience.

Took about a developer day to fix everything. Drag/drop list reordering, pan/zoom image cropper were the primary things busted. IMO, the change was an unacceptably aggressive move by the Chrome team made with good intentions.

> Drag/drop list reordering, pan/zoom image cropper

I'm curious, were these implemented using a 3rd party library or developed in-house?

Re: Chrome breaks the Web

#468

Earlier quoted context omitted.

> It's not protecting your interests, it's protecting Google's interests. But you can always install (or develop) another browser that might do this job better for you . > If it was protecting your interests, it would be a toggleable setting that defaults to normalized behavior. The problem with this view is that the vast majority of end users do not want, and in fact will never know about or use a new setting, and s…

IMO, breaking an established API with no reliable way to work around it is very bad. I have been bitten by this, and only now understand why. I will probably switch to Firefox.

Update: I switched to Firefox. Happy.

Re: Chrome breaks the Web

#469
post #431

Earlier quoted context omitted.

what for?

My best guess? Because he thought it would be cool. I'm not saying the decision makes sense. It obviously doesn't. But small organizations like a local church just don't have the expertise or resources to make good decisions about this sort of thing. Saying they deserve what they get is pretty unhelpful - it is completely unrealistic for them to hire someone who knows what he's doing. They can't fix that problem. So…

There's a huge difference between "getting screwed over" and "your cool scrolling effects having glitches".

Re: Chrome breaks the Web

#470
post #349

Earlier quoted context omitted.

> asking for the other user's password What? Why would the other user ever provide their password to this user?

How about an Administration interface that allows you to set a password to a known value for the user to use so they can log back into their account. So the helpful support person can now go "Your password is now 'foobar' and you will be asked to pick a new one when you login."

Why not let the administrative interface generate the temporary password and show it?
Post reply on HN