Hacker News Reader

Comment by ruipgil | Hacker News Reader

I might be the minority here, but I think that using the backspace to go back is counter intuitive. In my mind backspace is to delete something, and I always worry about that.

View on HN

This is great news. For some use cases, backspace-as-back is a disaster waiting to happen, for example, in a complex web app used in some time-critical task and that requires occasional deleting of text but can lose state or take a while to reload if you accidentally hit back. If you hit backspace without having a text field focused, the whole thing dies and needs to be reloaded and possibly checked to make sure it's still working right, while hundreds of people are anxiously watching and waiting. I have seen laptops with the backspace key physically ripped out just to prevent people from accidentally triggering its back-button behavior.

>I have seen laptops with the backspace key physically ripped out just to prevent people from accidentally triggering its back-button behavior.

how would you correct mistakes? with the delete button?

ctrl+x

Yep, delete button or else just use the default behavior of highlighting the full contents of the field to be changed. Mind you, these were dedicated machines that were specifically used for this one purpose and not something anyone would be using for, say, writing emails.

Giant web forms have been a usability disaster since day one. Accidental back button, link click, window close, session timeout, etc, increase the chance of a failure and need to re-enter the entire form. Whereas for at least 40 years desktop software has given you a "sure you don't want to save?" option.

Prompts do little to prevent accidental behavior as most just get clicked through without absorbing what they're saying.

I've lost HN comment data 10-15 minutes into a reply by using a laptop with an overly sensitive touchpad. Multiple times. Not something I particularly enjoy, and that's just a single input field.

Seems like the Chromium solution is to remove your touchpad.

Plain old web forms are actually not so bad these days, since browsers are pretty good about keeping any entered text around if you accidentally hit the back button (or even if the browser or computer crashes). It's really the big fancy web apps with lots of stateful javascript that are a problem, since the URL doesn't necessarily describe the state of the page and the form fields the browser tried to preserve may not even exist anymore. In the specific case I'm talking about, it was a big (and rather buggy) pile of stateful javascript, and whose failure would leave a crowd of angry sports fans and player waiting for it to start working again before the game could continue. In retrospect, not using in the the first place would probably have been the better option, but ripping out the backspace keys seemed like a reasonable compromise at the time.

It's an edge case, but we recently asked for this 'feature' to be removed from a framework we use because the app opens programs in the browser and does not modify the URl, so backspace took the user to the last URl in history, which was the login page. In other words, while the user was in the middle of some complex task, backspace logged them out and ended the session.

Glad to see it removed, alt+arrow-left/right still exist so the keyboard can still be used.

Right. The change in context is not clear enough for the average user (Text Field or History) and the consequences are really bad (loss of input text).

Does Chrome not prompt you about losing un-submitted changes to a form when triggering a navigation event?

I've never seen a browser do this. It's not clear to me it's a good idea, considering how widely input fields are used behind the scenes. Websites can request that the browser ask before navigating away, but I don't think a browser could reasonably do this automatically without getting it wrong annoyingly often.

Safari does it, and I don't remember the last time I got a false positive.

Most times, but not always. But it's better now at remembering what you typed if you accidentally navigate back then hit forward. I imagine in some situations I could accidentally lose form or input focus, hit backspace, and then lose everything. This could be an app that manually captures key presses with JavaScript rather than a regular input.

Sounds like an app like that should implement some kind of 'are you sure' using onbeforeunload. There are plenty of ways to navigate away from the current page (or close the tab/window) besides hitting backspace.

Have to admit using FF most of the time. I only know the sophisticated websites doing it themselves.

edit: chrome doesn't warn, but browsers can re-fill the input forms when you navigate forwards again. This doesn't help if the state of the website was more complex and fails to resume.

AFAIK it's done by javascript by the page.

(1) No, it does not.

(2) The concept of a "form" is less and less clear in the realm of web apps.

Yes, it does.

In the context of html in a browser, a form isn't a concept to be debated, it's a well understood element defined in the html standard.

If an app chooses to not use html forms and instead uses something like contenteditable to create its own editing environment, then you likely have much bigger issues than the back button.

I can't see how I have issues because a webapp I use wasn't perfectly coded. Remember the majority of browser users are, for a lack of a better word, browsers, not site developers. We can't affect the technology choices of the sites much, as choosing a site by tech purity instead of usefullnes is a losing proposition.

If I have a partially filled-out form that is really the query box for a search backend, and I hit back, why at the browser level should my flow be interrupted? That content was ephemeral.

It's an application-level question, not a system question. Can only be answered with semantic knowledge of the importance of the user input.

Hence we have get vs post forms.

It does not, but the page author can use javascript to generate a confirmation dialog when you're leaving the page: https://developer.mozilla.org/en-US/docs/Web/API/WindowEvent...

That kind of control is in the hands of the webapp.

For instance if I close this tab, where I'm typing the comment, there will be no prompt. Whereas facebook will prompt me if truly want to leave the page.

I don't think so - I have to build javascript onBeforeUnload checks into forms manually. So: you can protect against it (mostly), but only by annoying the other users who actually do want to navigate away. It's lose-lose.

Backspace to navigate is bloody hell. I don't know how much work I have lost because all I wanted was to remove a couple of characters. ALT-left arrow!

We're creatures of habit. In this case it's a behaviour that existed for two decades or so. Sure, it doesn't make much sense, but the same goes for various functions of the middle mouse button, depending on context: open new tab, close tab, open new application, close window, scroll, paste. Yet you don't see anyone changing those.

That's because those shortcuts don't usually end up losing all user input if somehow focus got moved off of the text entry field.

This is a change that should've happened a long time ago.

> Yet you don't see anyone changing those.

Except for (guess who?) Chromium...

https://bugs.chromium.org/p/chromium/issues/detail?id=255

They aren't removing middle click, they are just making it not fire off an onclick javascript event (to match the behavior of all other browsers).

Backspace and Escape have always had different behavior contextually. In videogames the Escape key is almost always "back".

Incidentally, Esc used to stop GIFs on a web page. Doesn't seem to do that (anymore?) in Chrome. (Oh, or Firefox, or Edge. IE is the only browser that still does that.)

IIRC there was some tedious justification for firefox about this being 'more correct' since escape would close websocket connections and pause javascripts and other fancy modern cruft sites rely on.

There's an extension (SuperStop I believe?) that partly restores it if you shift-esc, but recently I've found that invasive keybindings in pages (Slack, I think?) can intercept this and stop it working.

I'd really like a whitelist somewhere of what keys/combos I'd like the page to be able to catch, vs those which I expect and rely on to perform native functions, and which shouldn't be hookable (Github trying to cleverly intercept '/' and take you to the search field would be great, if / wasn't already a shortcut for searching the page, etc.

BetterStop [1] restores the old behaviour well.

[1] https://addons.mozilla.org/firefox/addon/betterstop/

The ridiculous thing here is that it's perfectly possible to make Esc stop animation without also stopping network connections. It's literally just a different argument to the stop function, and you can configure it just fine in BetterStop. But Mozilla couldn't care less, of course.

I suspect you are part of the silent majority. :)

This is why we're all really happy that no chrom* devs contribute to the vim project.

Haha. I'm an avid vim user and I don't get backspace. The normal key to move back by character is in the home-row. Why would I use backspace instead? Am I missing something?

You can use it without leaving insert mode.

Huh? In insert mode, the backspace does what it does in all editors. We're referring to the behavior in normal mode, where backspace is equivalent (I think?) to 'h', or left arrow in most editors.

this was a behaviour in other browsers a long time before Chrome started...

Reply on news.ycombinator.com