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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.