Likely related to https://codereview.chromium.org/1854963002

Oh, so this is intended.

1. How is someone who grew up in terminal times expected to navigate back when using a two-button mouse? Are you suggesting that the only remaining options are Alt-Left (a two-hand key combo for that I have to move my mouse hand towards the keyboard, and then back) and the back button left of the omnibox (for which I may have to move the mouse across much of the whole display height/width, and then back)?

2. Does this have anything to do with  Issue 329895 , too? This is another way of navigating back that has been (partly), silently removed. I have become more used to using backspace for back navigation BECAUSE the fourth mouse button has stopped to function as it should.

3. Why do you want to be so much different from other major browsers that still support back-navigation with backspace and the fourth mouse button while in the tab strip area?

4. The CL says:
"We're doing this via a flag so that we can control this behavior should there be sufficient outcry."

May I ask how I can change this flag in my Chrome installation?

I think #2 was possibly a regression that went unnoticed. I've reopened that bug.

The reason we're making this change is that users regularly lose data because they hit the backspace button thinking that a form field is focused. After years of this issue, we realize we're not going to have a better way to solve that problem.

We ended up not having a flag for this. Even if we had it, it would only have been in place for a single release.

Alright, I see. It should not be too difficult to create an extension to navigate back on backspace as a shortcut, right?

Correct. Building an extension for this should be very simple.

====================================

Good Build:

52.0.2715.0    Base Position: 388964


Bad Build:

52.0.2720.0    Base Position: 390547

=====================================

Able to repro this issue on Windows 7, MAC (10.11.4) & Ubuntu Trusty (14.04) for the Google Chrome Canary Version - 52.0.2723.0

This is a regression issue broken in M52, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/2c637da4df1dffc7412fb801cc670ea76b811879..4875d4b179e246bdc4a903bc3d20c831727eecca

Suspecting Commit: 6bb48eb86c7ecd5e735e945166075df48a16e828			

Review URL: https://codereview.chromium.org/1922993002

@ojan: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

I have same problem with Version 52.0.2723.2 dev-m (64-bit).
I do not want an extension to enable backspace navigation!!
Please repair this bug natively.

I had begun to try to develop an extension to fix this, but it is a bit expansive. 

In researching, though, I did find an extension called "Last Tab Back". It's main functionality is designed to close a tab via backspace when there is no longer a page to navigate back to. This feature can be turned off in its options, essentially restoring backspace functionality. 

However, this is a temporary fix. I think this change is a step in the right direction from an accessibility standpoint, but a flag to restore backspace navigation behavior would appease all. 

There is already an (unlisted) extension for this. The only drawback is that it is a content script, so it requires permission to read and change content on all websites. I can understand if someone does not want to give an extension such extensive rights for just a simple shortcut, but one may give it a try:
https://chrome.google.com/webstore/detail/backspace-back/fmphfaaenbdccndfgbkdplhidhchagfk

Adding to the outcry. If users lose data by navigating back in a form (somehow that has never happened to me in 15+ years of using browsers), there's always the Forward button, and Chrome saves and restores form data, does it not?

Please let Backspace do what it has always been doing.

I also use backspace as the primary method to navigate back (and have also never lost data using it...?)

I'm actually not sure what the best way to navigate back is anymore.

An extension that requires access to read the page contents doesn't sound ideal.

alt+left navigates back. Does that not work for you or were you unaware it existed?

We're planning on adding a notification about alt+left if users hit backspace more than once to educate about that.

I use backspace to navigate back very often and even though I know about alt+left, I find that alternative much more inconvenient to use, as it is a two-hand key combo, compared to a single key press. Removing this feature really makes my user experience with Chrome worse.

I have never accidentally pressed backspace in this context (i.e. when editing a form).

If you remove this, please make it a flag, just like Safari (http://apple.stackexchange.com/questions/167601/why-cant-i-go-back-with-backspace-in-safari-8) and Firefox (http://itsfoss.com/enable-backspace-firefox-ubuntu-linux/) do.

There will not be a flag for this.  We prefer that extensions, rather than options, be used to add non-default behavior in most cases.

@pkasting: I'm fine with using an extension that works as well as the original feature. Could you ship an official, tested one, before removing the feature please?

The third-party one I once tried when I was still using Linux barely worked and required too broad permissions - it had little glitches all over the place, interacted badly with syncing across to OS X and Windows, where backspace-for-navigation still worked natively, etc.

Did you also consider popping up a warning dialog "You have entered data in a form, would you really like to go back? [ Yes ] [ No ] [ Yes, never ask me again ]" instead of removing this feature? If yes, what were the reasons against it?

#16 -
While I do use Backspace for navigation, I did lose data due to accidental out-of-focus Backspace pressing a lot of times. :(
This change will teach me to use Alt + Left (while a little less inconvenient), which makes it far less susceptible to accidental data loss.

@pkasting, ojan -
In order to make it easier (and more performant) for extensions (and users), the keyboard shortcuts available to extension could also include the Backspace key (currently you cannot assign it when you go to chrome:extensions and click on "Keyboard shortcuts" at the bottom of the page).

Having a content script always active just for that does sound like a waste of memory.

Oops, I actually meant #14 and not #16.

#16 (for real) -
Chrome almost never adds dialogs. It generally only adds dialogs in cases extensions cannot prevent (shutting down the browser while downloading). I think extensions can preventDefault() the Backspace shortcut (say, after monitoring a form for changes), so a dialog would be an annoying way out. ;)
data:text/html,<!doctype html><script>onkeydown = e => e.preventDefault();</script>

Confirmation dialogs are almost always a bad UI decision; they prevent few accidental mistakes because users quickly learn to confirm the dialog as part of muscle memory, yet they also serve as a constant irritant ("just do what I told you to do").

As for an official extension, the closest thing is probably https://chrome.google.com/webstore/a/google.com/detail/backspace-b-back/gfdlpmpjpbepidnckbffioiegmlmlfhj , which was written by a Chrome team member.  You might test to see whether that works well.  (If so, we can advertise it more.  If not, maybe we can fix it.)

That extension is not public. What about my suggestion (comment 17)?

@20: I have no knowledge of anything in the extensions system, so any changes there would have to be filed separately and tackled by an actual extension developer.

I will contact the extension author for 19 and ask if they can publicize.

I wrote that non-public extension. Making it public is surprisingly complicated (the process for publishing an official extension is nontrivial, which is justified in most cases), but I'll start.

Philipp, could you point me to the third-party one you were using, so I can make sure mine doesn't have the same issues?

> There will not be a flag for this.  We prefer that extensions, rather than options, be used to add non-default behavior in most cases.

Why?

Chrome already has a ton of flags.

From a user's perspective, it just doesn't make sense to load an extension that eats up at least 8Mb of RAM, when essentially an "if" in the browser code would take care of that functionality.

Team policy is that flags only be used for short-lived testing and be removed afterward.  I have spent man-months of time trying to enforce that, and to the degree that exceptions exist that doesn't justify doing otherwise in general.  If we wanted this user-controllable in Chrome itself it would be an option, not a flag, and we have fairly few options which we are always trying to condense into fewer.

Using extensions for configurability is general policy, not specific to this issue.  Feel free to file bugs if this system is too resource-inefficient or in general has other problems.

(I mention "policy" here without justifying our policies, because I'm not going to spend the time explaining the origins of our policies on this thread, but these policies do have rationale and aren't just capricious.)

Is there to be a replacement single non-chorded keystroke?  Or at least a shortcut that doesn't make my wrist ache to hit?

PLEASE REVERT THIS CHANGE.

Sorry for shouting.  Using backspace to do this has been common practice for me for the last twenty years, and I have never lost data in a form with this.

This is most annoying. I have used this for the past twenty years and have not lost form data using it. In any event, chrome seems to remember form contents upon navigating back to a form page.

Leave my muscle memory alone please.

Forgive me if I misunderstood, but in the case where the user accidentally goes back, while thinking an input was focused, couldn't he/she go forward to the preserved state with the previously unsubmitted form data?

Anyone who thinks that form data loss is a non-issue is invited to review the following bugs (some dating as far back as 2010) and note the many, many, many complaints:

36533
144832
413395

Thank you for implementing this change, I have lost form data several times from this behaviour previously. Whilst I can sympathise with the naysayers, the problem for me is a real one, typically happens when typing into large text fields and inadvertently losing focus on the field. It is not good UX for the alternative behaviour of normal text input to do something as dramatic as changing the history state and potentially losing the user input data. Also note while the browser can re-populate forms when going forward in history, a lot of forms won't due to overriding native widget behaviours etc. If an extension is to be built for something like this, then it should be for people to opt into the behaviour not the other way around in my opinion.

Perhaps it would strike a better balance between tradition and usability if Chrome were to allow users to customize keyboard shortcuts for all (or, at least, all non-security-sensitive) user-initiated browser actions. This allows the Chrome team to set what they believe are sane defaults, but still allows advanced users (really anyone with moderate computing experience at all) to tailor their controls to best match their preferences.

This removes the overhead needed to run and install an extension, while not adding anything that would distract users (unless they actively choose to change said sane defaults), as it would be in chrome://settings (or wherever the Chrome team chooses).

I'm not arguing that data loss is a non-issue, but many people do not suffer from it. Catering to the lowest common denominator at the expense of proficient users by simply ignoring the proficient users is poor usability. Your users are not all inexperienced; treating them all as if they were hampers the user experience of one group in favor of another group.

If you can fill out a formular field correctly without losing focus, you are not part of Chrome's target audience.

edit: Had to type this four times due to accidently going back.

I don't seem to be able to edit my previous post, unfortunately. I apologize if anyone gets double notifications about this.

One other important UX factor is that developers/designers shouldn't prevent the user from doing common actions (backspace goes back in many, many programs). Instead, they should allow them to do those actions safely. Simply removing backspace because it's the easiest fix is not good usability. Perhaps the team would find that an improved user experience could be offered if they investigated other options (some of which may be harder to implement than the current solution). Maybe they could investigate why "...a lot of forms won't due to overriding native widget behaviours..." and then solve that problem.

More effort, sure. Better UX? Likely.

Why not disable backspace only when some form has data entered? Why remove the feature in all cases when the reason only applies to some?

Just for the paper trail: You identified the problem correctly, but are applying the wrong fix. The correct fix has been implemented by other browsers more than a decade ago.

The problem: Moving away from a form can result in data loss.

Your solution: Make it harder to move away.

The correct solution: Cache tab history completely and make it easy to move forward and backward in a tab's history by reusing cache and maintaining form contents.

Agree with Walde.

> We're doing this via a flag so that we can control this behavior should there be sufficient outcry.

For people living inside the insulated tech bubble they can just search, find this issue, realize its not a problem with their computer or keyboard or some page intercepting an event, but a decision made by the Chromium team, and maybe learn to get used to Alt+Left or go find one of those chrome extensions that are very simple to build.

What about everyone else? How will you know what your elderly users think? How does this change even get explained to them? They don't have the means of crying-out, this change is just another point of confusion you've added to their lives.

Ah someone who has last data numerous times in numerous web browsers because I hit the backspace when the focus was wrong, I'm happy about this change in default behavior.

While I appreciate it's a change in habits for many people, data loss is harder to deal with than a change in habits. If it can be solved easily with a flag or an extension, I hope that we keep this change as default behavior.

Hello friends from Hacker News! Marking this as WontFix and closing down the comments. We're definitely aware of the frustration that this causes users who have come to rely on the shortcut. We're working to release an extension that will allow users to restore this behavior. However for users who *don't* understand the behavior of the shortcut, which is the majority of users, the loss of data is also super frustrating and they are less equipped to understand or prevent their frustrations. [alt+left] and the extension will allow keyboard back navigation for users who want it while avoiding data loss for users who don't. It's not perfect but we think it's better than the world today. 

Tyler, can you post here the appropriate method for people unhappy with this change to provide their feedback in a way that we're sure to capture, when evaluating the reaction to this change?

Absolutely - feel free to send us feedback via the Menu > Help > Report an issue and/or star this issue to register your concerns. We are paying close attention to external reaction. 

FWIW not all stars are angry about the change. I am super happy to never lose or watch people lose state by accident again, but I want to follow this bug.

FYI, filed issue 613839 to explore extending the extension keyboard shortcut system to not require a content script for backspace.

 Issue 609746  has been merged into this issue.

 Issue 630816  has been merged into this issue.

 Issue 630827  has been merged into this issue.

 Issue 631286  has been merged into this issue.

 Issue 630353  has been merged into this issue.

 Issue 632355  has been merged into this issue.

 Issue 632322  has been merged into this issue.

 Issue 633793  has been merged into this issue.

 Issue 630353  has been merged into this issue.
 Issue 630816  has been merged into this issue.
 Issue 630827  has been merged into this issue.
 Issue 631286  has been merged into this issue.
 Issue 632322  has been merged into this issue.
 Issue 632355  has been merged into this issue.
 Issue 632403  has been merged into this issue.
 Issue 632470  has been merged into this issue.
 Issue 632475  has been merged into this issue.
 Issue 632977  has been merged into this issue.
 Issue 633793  has been merged into this issue.
 Issue 634462  has been merged into this issue.
 Issue 634904  has been merged into this issue.
 Issue 635229  has been merged into this issue.
 Issue 635348  has been merged into this issue.
 Issue 635445  has been merged into this issue.

 Issue 635586  has been merged into this issue.

 Issue 635915  has been merged into this issue.

 Issue 636530  has been merged into this issue.

 Issue 636547  has been merged into this issue.

 Issue 636217  has been merged into this issue.

 Issue 636201  has been merged into this issue.

 Issue 636582  has been merged into this issue.

 Issue 636698  has been merged into this issue.

 Issue 637820  has been merged into this issue.

 Issue 636942  has been merged into this issue.

 Issue 637283  has been merged into this issue.

 Issue 637595  has been merged into this issue.

 Issue 637535  has been merged into this issue.

 Issue 638125  has been merged into this issue.

 Issue 637611  has been merged into this issue.

 Issue 637590  has been merged into this issue.

 Issue 637267  has been merged into this issue.

 Issue 637487  has been merged into this issue.

 Issue 637511  has been merged into this issue.

 Issue 637029  has been merged into this issue.

 Issue 637082  has been merged into this issue.

 Issue 638331  has been merged into this issue.

Update: We have now published an official extension to restore this capability.

https://goo.gl/L30YZ7

Feel free to point other people at this.

 Issue 638886  has been merged into this issue.

 Issue 639023  has been merged into this issue.

 Issue 639630  has been merged into this issue.

 Issue 639851  has been merged into this issue.

 Issue 642960  has been merged into this issue.

 Issue 641229  has been merged into this issue.

 Issue 650471  has been merged into this issue.