Comment by revelation | Hacker News Reader

Comment by revelation | Hacker News Reader

As usual, they have chosen the worst possible "solution": removed the shortcut, didn't add an option. They did miraculously have time to flash up the two-key shortcut for back though, when they detect you pressing backspace multiple times.

Instead of, you know, taking that opportunity to show a simple popup of "do you want backspace to browse back?".

So now everyone has to install an extension that in the usual Chrome fashion can "read and change all your data on websites you visit."

I think for the next kind of feature they remove this way I'll add an extension that initially works and then have it auto-update to redirect people from everywhere to a petition site after a random interval. Just to point out the insanity in pouring lots of effort into security, sandboxing and even SSL only to force people to install auto-updated untrusted extensions that can access everything to bring back a minor keyboard shortcut. This is the exact kind of annoyance that will see people click yes yes yes on all kinds of red flashing security warnings.

removed the shortcut, didn't add an option

That's the right way.

"Never really remove anything, just wrap it in a default-off config option" is a horrendously bad way to build software. Every configurable option is an opportunity for bugs and an opportunity for misconfiguration.

If you are going to argue this, you might just as well start arguing that no programmer is allowed more than a quota of 10 ifs per month. Every conditional branch in your program is "an opportunity for bugs and an opportunity for misconfiguration".

This is the equivalent of hoisting a white flag. Theres tons of code added to Chrome all the time, it doesn't add configuration options but it sure as hell has the very same effect.

An if is just an inconsistent goto, so, yes. if is often a code smell.

For instance, any code like

    x = some_result()
    if is_valid(x):
        do_stuff_with(x)

is indisputably an opportunity for bugs. Better would be some construct like "if let" in Swift or Rust, where you can't use x without the condition. For instance, this was the fundamental cause of Apple's "goto fail" vulnerability: the language / API style required that they check each result and run a conditional branch on their own. (The proximate cause was bad language syntax, but the opportunity for bad syntax shouldn't have been there in the first place.)

I think it depends on the reason for the change. If the reason is primarily to reduce complexity or remove a buggy feature, it would make sense to remove the feature entirely from the code.

In this case, the shortcut is being removed because it's often unintentionally triggered by people who are not familiar with it, however there are also a lot of people who intentionally use it frequently. It could be reasonably argued that something like that should be configurable.

> That's the right way.

It's the lazy way.

You're right that it adds complexity. Every line of code contributes to complexity, and increases the number of places a bug could manifest. That's just the nature of software development.

Most software doesn't exist in a bubble of strictly-defined use cases. Software such as web browsers target a huge (potentially the broadest) range of users. Driving towards the lowest common denominator, as Google have been doing with Chrome by stripping configuration options over the years, doesn't result in a product people love to use. It produces software that performs adequately for the majority, and nothing more.

For features like "backspace to navigate back", throw them behind a flag. Make them default-disabled. Don't even worry about putting it in Preferences - tell power users who need it where they can find it (chrome://flags).

If you want an infinitely-customizable web browser which has everything available in a config option you're free to write one; multiple high-quality open-source engines are available to build around.

Not every feature is good or widely-used, and removing the ones that fail, rather than trying to keep them around but configurable, is simply the right thing to do.

You say "removing ones that fail", but surely that's the point here — it only fails for users who don't know what's going on.

If I deliberately reenable backspace as 'Back in browser history', I've no right to complain if I lose web app state; and if I get burned often, I'll disable it again. If I use it without any problems, what's the lose on Google's side?

Exactly. Taking your thought a step farther... You can enable the shortcut yourself via extensions! That way, there's no loss in Google's side. :) they don't have to maintain an obsolete feature, and any problems are yours, not theirs. You seem to have made their point for them.

Less code base to cover. Less tests. That's a win for the secs. And you're free to install an extension to retrieve the behavior of you want. Sounds like everyone wins.

Well taking that further, you could say the same with all keyboard shortcuts & they have nothing to test :)

Well, I'm free to install extensions on my own personal computer but not everywhere that I use Chrome.

Reply on news.ycombinator.com