This would be nice.  We've had a lot of comments that people are afraid of permissions that have the ability to access all your data on every site.

I have a nagging memory that in the last six months I looked up an issue where a while back we'd intentionally removed the ability for extensions to remap some particular key.  I'm wondering if it was backspace.

Why not let users assign any keyboard shortcut to any builtin function, bookmarklet, or extension?   Give the power to the users!

One problem with mapping backspace (and most other single keys, for that matter) is that it might be mapped even when the user is editing, which is obviously not desired. That means the system should provide a "also apply while editing" knob to the command. Sounds too techy for normal users (this regards the Keyboard shortcuts link in chrome:extensions), though, but I guess normal users will never assign keyboard shortcuts anyway, so maybe it is fine. Adding this knob to the commands extension API is obviously fine.

According to the Commands API page [1], "All key combinations must include either Ctrl* or Alt." So even with the "also when editing" knob, chrome.commands wouldn't support plain backspace navigating back.

Incidentally, right now it's hard for an extension to reliably tell when the user is editing. There are some unusual ways of creating an editable field. Does the browser itself always know?

[1] https://developer.chrome.com/extensions/commands

#4 -
This issue is exactly the desire to change the API to accept more than just Control or Alt combinations.

The browser surely knows, otherwise you would have gone back whenever you typed backspace in "unusual ways of creating an editable field". :)
It would have to consider e.preventDefault(), though (since it did at least up until now).

Also, this command cannot be a global command. The browser cannot know whether you are currently in an editing state outside of the browser.

As phistuck@ hinted at, the complication here is that command-handling for backspace would have to be significantly different than any other command handling, precisely because it is heavily context-sensitive (and the contexts are a little ambiguous sometimes).  Ultimately, it would need to be up to the browser, not the extension, to determine when to dispatch the event (otherwise the extension would definitely need to inject in every page, reducing performance and exposing all data).  In the end, unless we thought we wanted more shortcuts that fall into this very odd category, I think it would be much more reliable and performant to just add a "backspace goes back" API.  Of course, doing that means that Chrome gets no wins in simplification from removing support for backspace going back - I don't know if that was ever part of the motivation?

#7 -
As far as I know, the only motivation was unexpected behavior and data loss. I have never seen an argument other than those.

#7 -
Regarding the first part of your comment - I think enabling any key (even single characters, like n, p, o...) to be a shortcut would go through the same code path as backspace, which would be nice. Compatibility with web pages is the responsibility of the extension and the user, not of the browser (in non editing contexts, that is) in this case.

> Compatibility with web pages is the responsibility of the extension and the user
Sometimes yes, sometimes no.  In this case, no.  We always want to weigh the benefits against the costs, and make it easy to make great things while not encouraging bad practices.  The pain an extension intercepting all calls to 'c' can cause is very great (making it exceedingly difficult to navigate to chrome://extensions, e.g.), and I can't see any realistic use case for intercepting all calls to a vanilla input key (apart from IME extensions, which are an entirely different case and have a dedicated API).  I don't think that's ever something we want to enable.

Is it possible to bind to a non-standard single key like F2 or some keypad key and rather than have it be context sensitive, just have it work in all cases, maybe even when a text field is in focus but that's not really necessary? 

@7/10: I think it would be nice to be able to intercept calls to a non-modified keystroke.  See for example people who want to do vi bindings to control their browser.

I also don't think it's quite so painful here to "only intercept this when it's not otherwise handled".  At least for backspace we basically already get that for free in the code.  Just insert the handler in the right spot, and if backspace happens in a text field in web content, or the cursor is in the omnibox, or whatever, it gets eaten before it ever gets to the handler.

Hi, 

I am currently using https://chrome.google.com/webstore/detail/backspace-back/fmphfaaenbdccndfgbkdplhidhchagfk this extension to get backspace function back, it works flawlessly.

However, everytime I press backspace, Chrome shows "Press alt + ← to back"... how can I turn off this notification?

#13: That is hopefully fixed in v0.24, which also loads the content script at document start and thus makes going back multiple pages possible without waiting for each intermediate page to load.

Another reason behind this issue is that extensions cannot inject content scripts into chrome:// urls. (That's also one limitation of the above extension, and probably many others.) So whatever you decide to do to tackle this, please make sure it applies to all pages where backspace currently (v51) works.

Very strange to change this without having an option of user choice... 
This is 15 years of muscle memory that we have to retrain in a single update? 

My main argument against this approach: pressing two buttons very far apart means using two hands, this is not only very un-ergonomical but a bit ridiculous, its not like we are operating heavy machinery? Treat the user with some respect... 

Are we now also going to change the Android back-button? Have to hold volume-up + home button + click 'are you sure' :P

Least that could be done is put an option in chrome://flags like for all the other stuff.

30 mins later:

Also just realized that _right_-Alt + arrow-key actually changes the display driver's screen orientation. So in stead of going one page back, my screen tilts 90 degrees counter clockwise :)

Hence my ergonomics argument.

Also, why is  issue 608016  (https://bugs.chromium.org/p/chromium/issues/detail?id=608016) locked for comments?

#16 -
Totally off topic, but -
> Also just realized that _right_-Alt + arrow-key actually changes the display driver's screen orientation. So in stead of going one page back, my screen tilts 90 degrees counter clockwise :)
Wow, that is such an unbelievably stupid hotkey by Intel. I got technical support calls from friends and family because of this unbelievable stupidity.

It is closed for comments because they were probably not constructive anymore. Starring it is enough. Please, do not move the discussion here.

#10 -
I forgot to comment on this one -
> The pain an extension intercepting all calls to 'c' can cause is very great (making it exceedingly difficult to navigate to chrome://extensions, e.g.), 

No, because that is an editing context (the omnibox).

@18, currently extension shortcuts are greedy - they steel from everything, including existing shortcuts and handling.  For example, set a shortcut to ctrl+shift+v (paste without formatting) and try it in an editing context - the extension shortcut activates.  This is not to say that we cannot create an option for the api to have two shortcut settings - one which is prioritized and one which only activates if nothing else intercepts the key - but that is a significantly larger change than simply "allow more stuff as keyboard shortcuts".

This might come off as argumentative but this is a fairly major usability change, I thought something was up with my system / keyboard / browser until I saw backspace functionality was changed.

What is the criteria for functionality configurable via setting, flag, or require an extension?

I understand you have policies and there are probably good reasons for them which mandate this shouldn't be configurable (except by extension), but there is good reason to make an exception in this case.  User experience a big one IMO.

I try to run with as few extensions as possible (due to resource reasons), I'm sure other users do the same.  also an extension seems overkill for something like this.

looking forward to a solution that allows the old backspace functionality without an extension

Warning: this bug is only about possible modifications to the extension system.  It's not about restoring backspace as a shortcut, or anything else.  Given the potential for derailment, we will aggressively delete off-topic comments.

There are several excellent rebuttals to the "but extensions!" argument above.

This is an incredibly low bar to set for features requiring an add-on, to say nothing of the already pressing issues with extension bloat and naughty extensions.

It's an architectural discussion, which I think most would agree is "technical" in nature. 

The report is NOT for discussion at all.  This is only specific technical work required to allow extensions to support backspace as a keyboard shortcut.

General opinions about Chrome can be discussed at user forum:  https://productforums.google.com/forum/#!forum/chrome

Serious architecture/development discussion is at the developer forum:  https://groups.google.com/a/chromium.org/forum/#!forum/chromium-dev

Please do NOT post any more alternate suggestions nor alternate development suggestions here.

Marking as available with bugs /w an owner.

Locking to additional comments because people can't seem to read comment 24 or 31.

This is not the place to discuss, ask about, or complain about anything having to do with removing backspace as a keyboard shortcut.  Apparently it was too difficult to understand this the first couple of times we said it, so now commenting here is entirely closed.

 Issue 635915  has been merged into this issue.

 Issue 641842  has been merged into this issue.