Why does backspace go back a page? This behavior is so frustrating!

  • When using a browser, like Firefox, I appreciate that I can easily navigate my tab history with Alt+ (for back) and Alt+ (for forward.) That makes perfectly good sense to me, and I've used that keyboard shortcut for the longest time.

    I frequently do text input in web pages. On some pages (but not all) when I want to erase the last few characters I just typed, I tap Backspace several times. Tap tap tap. And then, lo-and-behold, my browser is leaving the page I was on and going back in the tab history. I may have lost what I was writing. And I am a very unhappy user.

    Chrome developers have decided to remove this, see this story from Ars Technica:

    Google hovers over delete button for backspace nav shortcut in Chrome Google: Only 0.04 percent of page views navigate via the backspace button. ... We have UseCounters showing that 0.04 percent of page views navigate back via the backspace button and 0.005 percent of page views are after a form interaction.

    This means that up to 1 in 8 backspace navigations could be losing user data.

    I hypothesize that many of these are accidental - I lost text again a few days ago because of this feature.

    Why did browser creators think this is such a great feature? Alt+ is unambiguous. But to overload the Backspace key with this behavior is atrocious! I can see from a quick Google search that many others are frustrated by this.

    • How did this come about?
    • Is the standard default behavior too strongly established to reverse course?
    • Can we change it, and what would be the plan to do so?

    Canonical paths to blocking this

    I'll be logging the canonical ways to turn this off for browsers here, and I do not want to see software add-ons here:

    This blog entry by Jeff atwood would also apply: http://blog.codinghorror.com/the-opposite-of-fitts-law/ and it seems discussed a great deal in this chromium bug report: http://code.google.com/p/chromium/issues/detail?id=144832 but I'm not qualified enough for it to be time-effective for me to attempt to answer.

    That bug report is very interesting! It is almost a usability test report in itself! :)

    I saw that, @Peter and I do NOT appreciate being told to install third party software from an developer of no reputation. I hope someone will **Make an excellent canonical answer** that thoroughly discusses the ins and outs of removing this as a default behavior in browsers for user experience. and for the record, this is the canonical way an individual would change the default in Firefox: https://support.mozilla.org/en-US/questions/924490

    @AaronHall, I'm assuming your ire is directed at the article rather than me for trying to help you. As the article states, Firefox does not require any additional installs.

    I created a gist of a suggested answer outline for what I might consider would be the best answer: https://gist.github.com/anonymous/9279297

    I don't understand. Backspace **never** goes back a page when the focus is on a textfield, such as a textbox, address bar etc. This behaviour is the same even in Windows Explorer. As long as Backspace is constrained to a textfield, you can go on pressing it, and the browser/window will never leave the current page. Morever, you never type when your focus is _not_ in a text field, so the overloading of the backspace is perfectly justified.

    @SNag you're welcome to form an answer defending this feature, and we can see how well it fares. If you do a good job, I'll +1 and ask people to judge on the merits, and not whether they disagree with the feature, no joke. :)

    @SNag have you tried doing what various users might do, perhaps interacting with page elements, highlighting text you want to mentally bookmark, scrolling up and down with your mouse wheel, clicking it and dragging to adjust finely, resize your text box, and go back and forth between these activities while editing text? You know, just do what a User Acceptance Test-er might do.

    I'm afraid for Chrome the only fix is a software add-on.

    On linux Mozilla disabled the backspace key mapping since 2006-12-07

    @OllieFord I do not view software add-ons as an acceptable solution. We can see from Google's product forums the degree to which this frustrates so many people to write with a great deal of animosity, and with a great deal of support. Those writing in the support of the *bug* (it's a bug not a feature) seem to be coming across as trolls. https://productforums.google.com/forum/#!topic/chrome/LnpPdwaWvqI

    Oh I know - I just meant you can't include the fix in your post, since it does require an add-on. (Or changing the source, even worse!)

    I wanted to add that I use the backspace quite a lot, and have found the opposite situation which might shed light on why Google likes it. When I hit a google search in my history, hoogle quickly puts the text focus in their main box so my backspace now starts erasing what I wrote rather than going further in the history, and I consider doing another search.

    As an aside, I quite like it and use it ridiculously often. While browsing, my hand rests on the area with home, page up/down, end, and the "vaunted" backspace. That area on the keyboard is mapped towards all buttons that are useful for browsing, and it makes browsing a breeze.

    There *are* people who are either a) cursor-focus savants, b) people who never edit their text online, and c) people who don't mind being unproductive by losing their work. I don't think that justifies leaving the *ejector-seat button doubling as a heavily used editing button by default*. Using an Internet Browser is much more of a breeze when you can worry about other things than losing your work. You can see there's also an answer below that removes your pathological functionality, but it doesn't remove the functionality of the brilliant [Alt]+[←] keys. Safer to learn those, I would suggest.

    Also please note there is a **Shift+Backspace** shortcut which implements **Forward** command.

    It's the same for Return meaning newline or commit.

    More than a year later, "hey, this is too ranty, I'm voting to close." So you're a bit late to the show. However, the question is clearly stated. Maybe you're a cursor-focus savant, but if you disagree with the premise, make the case in a **good** answer that addresses the question as given, and I'll upvote you. If this is closed, you won't be able to. If you really don't think this is a problem, you should see the real rant that popped up here a few days ago. But you'll probably need more rep, as it was deleted.

    I've never had this problem

    @SNag - It's far too easy to lose focus on the text field for whatever reason. I'm posting this almost a year and a half after your comment after encountering the same problem, and reading through the bug report page of many other users encountering the same problem. I don't think the overloading is even close to justified.

    Chrome has "fixed" it from version 52. But its a lame fix. ignoring the real problem. The problem wasn't backspace itself, it was inputs loosing control and redirecting to other page when there were unsubmitted data. Proper solution would be to ask user if he/she really wants to navigate to other page when there are data that wasn't submitted. Just like the StackExchange does when you start typing answer and then click on link, you are prompted and warned about potential lose of data ...

    As someone who absolutely loves having backspace go back (to the point of using a chrome extension to reenable it): When I'm working on a project across multiple windows and tabs, I'll abandon the cursor. Relative to the keyboard, it is slow and unwieldy, and breaks my flow to have to move my hands away from the home row, while everything I need to do can be done with keyboard shortcuts and alt-tab / shift-tab. Backspace is the perfect button for browsing with, as I use the web for documentation, not form-filling. As with the cursor, alt-left arrow requires I move my hands; Backspace does not.

    I agree. Backspace goes back when an user try to change a field with readonly attribute.

  • pathfinder

    pathfinder Correct answer

    7 years ago

    I don't know how it started but I can add my two cents about what ALL my clients say:

    $%!$% what the @$#%#% just happened? Why did the page change? Now I have to fill in that form all over again.

    I would love to see this go away for good, and the first thing I do when building a form laden website is the following jQuery script:

    var hasfocus = 'false';
    
    // when focus happens, set a variable
    $(document).on('focusin','input, textarea',function() {
        hasfocus = 'true';
        });
    
    // unset when focus is not happening    
    $(document).on('focusout','input, textarea',function() {
        hasfocus = 'false';
        });
    
    // if not in a form field, stop backspace and delete default action
    $(document).keypress(function (e) {
        if(e.which == 8 || e.which == 46) {
            if(hasfocus == 'false') {
                e.preventDefault();
               }
           }
        });
    

    I would love to see how other people handle this in javascript without jQuery too. And I have used this code for years with no complaint, but if there is a better way I am all ears :)

    StackOverflow would be the place to provide this type of answer. In fact, artificially capturing the backspace key and altering its behavior is poor UX. The user should not have to relearn what a certain key does on your web site versus every other website.

    I think a lot of heavily used sites that are very focused on user experience are actually doing this.

    hey closet monkey, as my answer states, not one of my clients (or users) knows the backspace is supposed to do that, so I am actually making the UX be what they expect. In fact, not one of the people filling out a form and actually unfocusing from the text field wants to go back a page and lose all the data they just input. It is especially painful on a joomla or wordpress site when you spent an hour writing an article and accidentally do this.

    plus I stop my users from cursing at their computers, so I would expect that the user experience for them is greatly enhanced :)

    It doesn't matter if this is some useful code; that was not what was asked for. Plus you haven't actually provided an answer to the question anyway. The question is about the reason for this behavior existing.

    I guess when going forward again the form should just be at its prior state. Removing the behaviour for a key isn't that nice either.

    Ah, that's why I wasn't able to reproduce it on UX.se

    +1 for @Luc's comment. Sane browsers will refill your data when you go forward anyway.

    @Indy Yeah, well, usually. Some smart websites think contenteditable divs or other customized stuff (tinymce or what have you) are the solution to everything, and those are so scripted that the browser can't save them. Good old textareas aren't such a bad idea after all...

    @Luc I mourn the days of global NoScript support.

    I tell you what, I really like this answer not because of the code, but because it demonstrates that this is such a pathological behavior that sites have had to come up with a way of over-riding it. It should certainly not be default behavior, but I'll allow that users should be put in control. Nevertheless, for your own productivity and sanity, I would suggest you familiarize yourself with [Alt]+[←] unless you're a cursor-focus savant.

    I was adding my comment, and nothing more. This is a good place to have this script handy. Plus, UX = User Experience, and for my clients and users, I have made their experience better, so I would choose to do that over "bad practices" any day. I would definitely support changing the default behavior by the browser vendors. It is not like there is another button right next to backspace that goes forward a page, so it is not well thought out.

    Changing from the default behavior is especially useful when creating a web based application internally used by a company to manage data via forms of all kinds. It is not so necessary if it is just a web page for reading. As my answer states, I use this for form laden sites and pages.

    Anyone use gmail lately and select some text in the email they are writing and click the delete button? Even though I have text selected and am in some pseudo form of a textarea (the compose email box), sometimes my browser goes back a page. We would call this a "bug" in the gmail site, but damn is it frustrating to deal with. Hopefully google will implement something to make it stop one of these days.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM