Closed Bug 1041377 Opened 10 years ago Closed 3 years ago

Disable Backspace as a shortcut for navigating back in history

Categories

(Firefox :: Keyboard Navigation, enhancement, P3)

30 Branch
enhancement

Tracking

()

RESOLVED FIXED
86 Branch
Tracking Status
relnote-firefox --- 87+
firefox-esr78 --- wontfix
firefox84 --- wontfix
firefox85 --- wontfix
firefox86 --- disabled
firefox87 + fixed

People

(Reporter: Unfocused, Assigned: cpeterson)

References

(Blocks 4 open bugs)

Details

(Keywords: parity-chrome, parity-safari)

User Story

We should not ‘overload’ common user actions. With Backspace, it behaves as you would expect in one context, deleting text, but in another subtle context (text box not selected) it has a destructive action of changing the page. This creates a high likelihood scenario for a common user behavior, deleting text, to trigger a less likely user behavior “using a keyboard shortcut to navigate back.” This investment resolves the overloaded function and closes the gap on user behavior.
Firefox is the only browser using the “Backspace” key as a keyboard shortcut for navigating to the previous page on a tab, this was originally implemented to follow IE’s behavior. We don't go to the previous page if you use the shortcut inside a text input although there are several reasons that make a good case for removal of this shortcut:
- The argument to retain “Backspace” keyboard shortcut for muscle memory for users migrating to Firefox or using Firefox along another browser does not apply anymore
- Edge has now replaced IE as a default Windows browser without a similar shortcut (Alt + Left Arrow is the only keyboard shortcut available for this)    
- Chrome also only implements Alt + Left Arrow
- Chrome had this shortcut and removed it because of user data loss risks 

The “Backspace” keyboard shortcut on Firefox is by far the keyboard shortcut with highest usage with 40M MAU, well above “Find in page” (16M MAU) or “Page reload” (15M MAU), causing concerns that our users suffer useability issues and data loss issues from hitting this keyboard shortcut by mistake

Attachments

(3 files)

Pressing backspace does different things depending on where the cursor is. If it's in a text input field, it deletes the character to the left. If it's not in a text input field, it's the same as hitting the back button. 

Whether to keep this behaviour has been argued For A Very Long Time. It's confusing for many people, but we've assumed it would break muscle memory for many people. Howefver, the muscle memory argument was mostly an assumption - AFAIK, we didn't have useful usage data. Until now.

So: Now we have (or can get) useful usage data to either backup the muscle memory argument, or to squash it once and for all - and remove backspace as a shortcut for navigation.
Flags: firefox-backlog+
Are these data publicly available somewhere?
Blocks: 916408
Blocks: 1195831
I guess we can probably add a pref for that, so that users don't like it could switch it off, and if we decide to turn it off by default in the future, users who miss it can still enable it themselves.
We already have "browser.backspace_action".
I don't think it's a good idea to remove backspace as a shortcut for navigating back in history and I want to explain why I think so.

Google removed this shortcut because of low usage and to prevent data loss. I cannot speak for other operating systems but I am using Apple OS X. If backspace as shortcut will be removed I have to use Cmd + Cursor left. While backspace is the shortcut for removing the last character in a text field, Cmd + Cursor left is the shortcut to jump to the beginning of the line. I don't know why Cmd + left should result in less data losses than backspace. Maybe Cmd + cursor left is not more worse than backspace, but it's also not better, it's just a another key conflict and risk…

By the way, in the past Cmd + cursor left resulted *much more often* in data loss for me than the backspace key. So based on personal experiences this change would not prevent data losses for me, it would result in more data losses…
How is it loss data to jump to the beginning of the line?
That's not data loss. And it's no data loss to remove the last character. Google argued that it results in data loss (if you press the key are are outside of the a text field).

https://codereview.chromium.org/1854963002

> We have UseCounters showing that 0.04% of page views navigate back via the backspace button and 0.005% of page views are after a form interaction. The latter are often cases where the user loses data.

Safari 14 (macOS 11 Big Sur) doesn't navigate back on Backspace.

Firefox on Linux already doesn't navigate back on Backspace. Bug 325541 made this change in Firefox 2 to match Linux platform conventions.

So the only mainstream browsers that navigate back on Backspace in 2020 are:

  • Firefox on Windows and macOS
  • IE11 on Windows (Chromium Edge does not)
Depends on: 325541
Summary: Investigate removing backspace as a shortcut for navigating back in history → Investigate removing Backspace as a shortcut for navigating back in history

I updated the user stories with details on context about why this is a priority.
My understanding is that the scope of change is limited to setting the preference browser.backspace_action to 1, I can work with SUMO on keyboard shortcut document updates.

User Story: (updated)

(In reply to Romain Testard [:RT] from comment #10)

My understanding is that the scope of change is limited to setting the preference browser.backspace_action to 1, I can work with SUMO on keyboard shortcut document updates.

I think we want browser.backspace_action = 2 (do nothing), not 1. With value 1, Firefox will treat Backspace like PageUp (scrolling up the page), which is not the behavior Chrome, Edge, or Safari. They all do nothing on Backspace.

https://searchfox.org/mozilla-central/rev/0d6e8b21569f93a1e1ae8e377ab10f43a6cb12c1/browser/app/profile/firefox.js#831-839

// Backspace and Shift+Backspace behavior
// 0 goes Back/Forward
// 1 act like PgUp/PgDown
// 2 and other values, nothing
Flags: needinfo?(rtestard)

Agreed, we want browser.backspace_action = 2 (do nothing),. Thanks for verifying!

Flags: needinfo?(rtestard)

I have a patch to disable the Backspace keyboard shortcut and fix affected tests.

Assignee: nobody → cpeterson
Severity: normal → N/A
Type: defect → enhancement
Priority: -- → P3

We want this test to keep working after the Backspace keyboard shortcut is disabled (browser.backspace_action pref = 2) in Firefox on Windows and macOS. This test_back_keyboard_shortcut test case was previously skipped on Linux because browser.backspace_action was already 2 on Linux.

We want this test to keep working after the Backspace keyboard shortcut is disabled (browser.backspace_action pref = 2) in Firefox on Windows and macOS. This test_keyboard_history_navigation test case was previously skipped on Linux because browser.backspace_action was already 2 on Linux.

Depends on D100531

This change aligns Firefox on Windows and macOS with the behavior of Firefox on Linux, Chrome, Edge, and Safari. The only mainstream browsers that navigate back on Backspace in 2020 are Firefox on Windows and macOS and IE11 on Windows.

Depends on D100532

Try run for test refactorings part 1 and 2 (before disabling the Backspace keyboard shortcut):

https://treeherder.mozilla.org/jobs?repo=try&revision=0dc3fa6313cb059051147f7490c118b568bd399c

There are quite a few orange test failures, but none of them are in the tests I refactored.

Try run for part 3, disabling the Backspace keyboard shortcut:

https://treeherder.mozilla.org/jobs?repo=try&revision=c46f3e139a9e0caf43ba98351f5f3f9ff1686d71

There are quite a few orange test failures, but none of them are in the tests I refactored or related to back/forward history navigation, AFAICT.

Pushed by cpeterson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e49a4a3259b3
Part 1: Change passwordmgr test to navigate using Alt + arrow key instead of Backspace keyboard shortcut. r=MattN
Pushed by cpeterson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ead0e08a13bb
Part 2: Change history test to navigate using Alt + arrow keys instead of Backspace keyboard shortcut. r=masayuki
https://hg.mozilla.org/integration/autoland/rev/b1be428bb5d9
Part 3: Disable Backspace as keyboard shortcut for back/forward navigation on Windows and macOS. r=masayuki

Release Note Request (optional, but appreciated)

[Why is this notable]: Disables a keyboard shortcut that has been around forever. Some users will be annoyed, so we should document the rationale for this change and how to re-enable to the old behavior.

[Affects Firefox for Android]: In theory yes, but not worth mentioning since few Android users will be navigating using a keyboard.

[Suggested wording]: To prevent user data loss when filling out forms, disable Backspace as a keyboard shortcut for "Go back one page" navigation. To re-enable the Backspace keyboard shortcut, change the about:config preference browser.backspace_action to 0.

[Links (documentation, blog post, etc)]: This Support article documents other Firefox keyboard shortcuts for "Go back one page" navigation, such as Alt or Command + Left Arrow: https://support.mozilla.org/kb/keyboard-shortcuts-perform-firefox-tasks-quickly

Is there significant cause to believe that the accidental use of this shortcut frequently causes data loss, other than its high use? I concede that it might be somewhat easy to accidentally misuse, but I'm not entirely sure if that's a bad thing - I find backspace to be a much easier shortcut than, say, alt+left arrow (which I didn't know existed until reading this thread). I discovered it by accident, but I didn't lose data as a result (how frequent would this be? I imagine forms are a small portion of web content, although backspace may be used by accident more commonly there), and now I find it a useful shortcut (the lack of which irritates me when forced to use other browsers).

The contents of most forms can be saved by going back forward in history (although there are exceptions, and there is probably a group of users - a similar one to those who would accidentally trigger this shortcut - who might not know that and would probably just click whatever link/button took them to the page again instead of going forward in history), something which was likely not possible in other browsers when this feature was removed (or not added).

Is it technically feasible to warn a user when going back that data may be lost, instead of removing the shortcut entirely?

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch

We should not ‘overload’ common user actions. With Backspace, it behaves as
you would expect in one context, deleting text, but in another subtle
context (text box not selected) it has a destructive action of changing the
page.

The down or up arrow has the same issue. If you are in a textbox it will move your cursor but scroll the page otherwise…

This was the first thing I hated about Chrome. Why do you want to replicate all of the features? Users can be very used to using backspace to select a last page (I am) and now they will be lost. I can change the setting (although I have to remember to do it in every installation of Firefox) but a normal user wouldn't do that and just say a few bad words.

Do you know what's the usage of that key for history browsing? Is there any telemetry?

(In reply to Bartosz Piec from comment #26)

This was the first thing I hated about Chrome. Why do you want to replicate all of the features? Users can be very used to using backspace to select a last page (I am) and now they will be lost. I can change the setting (although I have to remember to do it in every installation of Firefox) but a normal user wouldn't do that and just say a few bad words.

I feel you, since I previously navigated with Backspace often, too, but I feel this change is good for users overall. I like the perspective shared in Chromium bug 413395 comment 17:

The backspace accelerator hurts our least experienced and least knowledgeable users at a moment when they are stretching the envelope of their skills (filling in a form, i.e. moving from passive web consumption to interaction of some kind). Compared to that, the harm inflicted on a more experienced user that is forced to relearn an accelerator is much less.

Unlike Chrome, at least Firefox still has an about:config pref for power users to restore the previous behavior: set browser.backspace_action = 0.

Do you know what's the usage of that key for history browsing? Is there any telemetry?

We have keyboard shortcut telemetry (https://sql.telemetry.mozilla.org/queries/75624), though that raw data is not public. But here is a summary of some keyboard shortcuts and how many Firefox users use each per month. (Note this is the number of users, not number of times the shortcut was used.)

Shortcut Users Per Month
Backspace back navigation (cmd-handleBackspace) 40M
Browser:Reload (Ctrl+R or toolbar button) 15M
Alt + Left Arrow back navigation (goBackKb) 2M
Alt + Right Arrow forward navigation (goForwardKb) 0.5M
Shift+Backspace forward navigation (cmd-handleShiftBackspace) 0.3M

We can't read the minds of those 40M Backspace users, but the ratio of back/forward navigation is much different for Backspace/Shift+Backspace (133x) compared to Alt + Left Arrow / Alt + Right Arrow (8x). I think this suggests most Backspace users are behaving much differently than Alt + Arrow users, probably because they are navigating with Backspace by accident.

Summary: Investigate removing Backspace as a shortcut for navigating back in history → Disable Backspace as a shortcut for navigating back in history

(In reply to Chris Peterson [:cpeterson] from comment #22)

Release Note Request (optional, but appreciated)

I added this change to our Nightly release notes with some rewording to mention the recommended shortcut:

To prevent user data loss when filling out forms, the Backspace key as a navigation shortcut for "Go back one page" is now disabled. To re-enable the Backspace keyboard shortcut, you can change the about:config preference browser.backspace_action to 0. You can also use the recommended Alt + Left arrow shortcut instead (Firefox keyboard shortcuts).

Consider mentioning that for Mac users, this is Command + Left arrow (on Mac, Alt usually translates to option)

Flags: needinfo?(pascalc)

Joni, just pinging you here for awareness that this change will need documentation changes on https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly when it gets to release.

Flags: needinfo?(jsavage)

(In reply to Romain Testard [:RT] from comment #31)

Joni, just pinging you here for awareness that this change will need documentation changes on https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly when it gets to release.

btw, I submitted a SUMO fix for review here:

https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly/revision/213629

https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly/history

Did we consider preserving the behaviour for existing users?

Flags: needinfo?(cpeterson)

(In reply to :Gijs (he/him) from comment #34)

Did we consider preserving the behaviour for existing users?

I hadn't considered that. It should be straightforward to implement. I will defer that decision to Romain on the Desktop PM team.

Do you know of a good example of an existing feature pref that we treat differently for new profiles? I assume I would add a check in the updater's profile version migration.

Flags: needinfo?(rtestard)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(cpeterson)

(In reply to Chris Peterson [:cpeterson] from comment #35)

(In reply to :Gijs (he/him) from comment #34)

Did we consider preserving the behaviour for existing users?

I hadn't considered that. It should be straightforward to implement. I will defer that decision to Romain on the Desktop PM team.

Do you know of a good example of an existing feature pref that we treat differently for new profiles?

https://searchfox.org/mozilla-central/rev/a0ccd492719b1ad2106f6456549be62a76f45acb/browser/components/BrowserGlue.jsm#3371-3381 perhaps. Basically, all the profile migration code there will only run for existing code, there's a check at the top of _migrateUI that bails early for new profiles.

Note that this won't depend on usage / "understanding" of what the shortcut does, it'd just keep the shortcut working for all existing profiles, and it'd not work (by default) for new profiles / after a profile reset.

Because of this, I'm not actually 100% sure if it would be the right thing, on balance - though it'd certainly avoid the immediate confusion around the change, it may result in less discoverable / more confusing breakage for users who set up Firefox on a new machine / for a new user account / run a "refresh Firefox".

I assume I would add a check in the updater's profile version migration.

in BrowserGlue.jsm, yeah.

Flags: needinfo?(gijskruitbosch+bugs)

Would it be it be feasible to popup the first time an (existing?) user does it, either offering to set browser.backspace_action, or telling them it's an option? For me, it's a feature that I use several times a day that just... stopped working, and I came here to report it as a bug, like bug 1685049. Because this bug is "RESOLVED" (as is that one), it does not show up under a casual search.

Perhaps many of the 40M users do not intend to go back when they press backspace; however, even if (and this is not clear) it's a small percentage that do intend to use it, it's a feature that will appear "broken" for literally millions of people as well, once this lands for them.

Regarding the divergence in back/forward noted in comment 27: often I'm going back from visiting a link in the preceding page; so if there is a balancing action, it's that I'm visiting another link on the preceding page, or using it in other ways. The lack of going forwards does not indicate that going back was unintentional. I didn't even know shift-backspace would go forward, as this is non-intuitive; nor did I know alt-left/right.

I'd echo comment 23's suggestion that if part of the problem is the loss of form data, gating navigation if data has been changed or preserving it so that you can come back to it by going forward (which I think is done much of the time, like here, but could certainly be improved?) is a better response, and would help when people inadvertently go backwards or forward via another method; or perhaps close the tab, restart browser, etc. Perhaps it may be tricky to determine when a change in form data has occurred through user interaction, but such is life.

(FWIW, I also tried to pre-set browser.backspace_action on my Surface Pro with Developer, but I can't because it's already set to 0 - the default.)

Blocks: 1481311
See Also: → 1659712

When comparing users of the back and forward chrome buttons with users of the back and forward keyboard shortcuts (users of the shortcut / users of the button) we get:

  • Back usage: 0.339 (i.e about 3 times more button usage than shortcut usage)
  • Forward usage: 0.01 (i.e 102 times more button usage than shortcut usage)
  • 118M users use the back button monthly, and 40M use the keyboard shortcut. If we apply the forward button ratio as a proxy we see that only 1.18M users would use the keyboard shortcut - implying that we cause pain to more than 38M users monthly with the Backspace shortcut

The above signals a clear issue for users but I totally agree that a share of users may be used to the shortcut and will suffer from the change.

My opinion:

  • It seems obvious that the change should apply to new profiles
  • For existing profiles, there is no great way to identify users who like the shortcut. Given the clues that vastly more users suffer from the current behavior than benefit it I think we should make the change. We need to communicate it as well as possible so that users noticing the change can find out what happened and how to adjust preferences when needed.
  • Prompting users who attempt to use the Backspace shortcut to tell them about the new shortcut seems bound to confuse most users prompted.
Flags: needinfo?(rtestard)

(In reply to Romain Testard [:RT] from comment #38)

  • 118M users use the back button monthly, and 40M use the keyboard shortcut. If we apply the forward button ratio as a proxy we see that only 1.18M users would use the keyboard shortcut - implying that we cause pain to more than 38M users monthly with the Backspace shortcut

This makes an incorrect assumption: that people always use shortcuts if they know one shortcut. I use the forward button, but the back shortcut. I did not know about any of the forward shortcuts. Shift+Backspace is not used in e.g. Windows Explorer. Alt I only use outside Firefox, for Alt+Tab. (Admittedly, I do know Shift+Alt+Tab, but I had not extended that to back and forward in Firefox, because it's not a carousel like Alt+Tab is.)

People go back far more often than forward, which is why a single-button shortcut is beneficial. Those who found it may have continued using it.


I notice that Edge has a tooltip, "Click to go back (Alt+Left arrow), hold to see history". Firefox only has "Go back one page [/n] Right-click or pull down to show history" and does not mention a platform shortcut. Promoting Alt+Left/Right there (and appropriate alternatives on other platforms) could help those disadvantaged by this change.

I use the forward button, but the back shortcut. I did not know about any of the forward shortcuts.

Almost the same here. I didn't know about Shift+Backspace but I knew about Alt+Right (or Cmd+Right on macOS) and I never used this shortcut because it needs to keys. So I used Backspace as a shortcut for the back navigation but never used a shortcut for navigating forward.

(In reply to Laurence "GreenReaper" Parry from comment #39)

I notice that Edge has a tooltip, "Click to go back (Alt+Left arrow), hold to see history". Firefox only has "Go back one page [/n] Right-click or pull down to show history" and does not mention a platform shortcut. Promoting Alt+Left/Right there (and appropriate alternatives on other platforms) could help those disadvantaged by this change.

Could you please file a new bug on this?

(In reply to Sören Hentzschel from comment #40)

And while it's true that the accidental use of Backspace can have data loss implications please note that the same applies for the new promoted shortcut as well. In fact on macOS it caused much more data loss situations for me than backspace in the past, see my comment from five years ago. I am a user who uses Cmd+Left a lot to move the cursor to the beginning of a text field, much more than I need the back navigation. And it's exactly the same situation: It's an overloaded shortcut with a different function inside and outside of text fields. The same reasoning would apply here as well.

Correct me if I'm wrong; this appears to be a Mac-specific problem, I don't think the shortcuts overlap on other platforms. It's also somewhat irrelevant to this bug in the sense that disabling the backspace trigger for accidental navigation wouldn't make your accidental navigation problem any worse, contrary to what you wrote five years ago.

contrary to what you wrote five years ago

You're right. I submitted my comment too early and made a few changes to my comment after thinking more about it. One change was removing this reference to my comment from five years ago. Unfortunately you was faster with reading my comment than I with correcting my comment. :) What I actually wanted to say was that the situation for both shortcuts is very similar and the same reasoning for changing the back navigation shortcut would apply here as well. But yes, that's probably Mac-specific and not directly related to this change. I should have marked this as off-topic or left it out altogether (probably the best option). ;-)

I removed this off-topic part from my last comment now to keep the focus on the backspace change.

One of the reasons I switched to Firefox was because they changed the behavior of the backspace. So let me start with the fact that I'm happy to restore the behavior (unlike Chrome).

My primary reason for restoring it is that backspace is can be done with a single hand. While ALT+LEFT is actually ALT_LEFT+LEFT and doesn't support ALT_RIGHT+LEFT. So I would require two hands.

(In reply to Romain Testard [:RT] from comment #38)

When comparing users of the back and forward chrome buttons with users of the back and forward keyboard shortcuts (users of the shortcut / users of the button) we get:

  • Back usage: 0.339 (i.e about 3 times more button usage than shortcut usage)
  • Forward usage: 0.01 (i.e 102 times more button usage than shortcut usage)
  • 118M users use the back button monthly, and 40M use the keyboard shortcut. If we apply the forward button ratio as a proxy we see that only 1.18M users would use the keyboard shortcut - implying that we cause pain to more than 38M users monthly with the Backspace shortcut

The above signals a clear issue for users but I totally agree that a share of users may be used to the shortcut and will suffer from the change.

The "shortcut telemetry" is not conclusive proof of the undesired behavior for that we need to compare the various use cases of the backspace.
Examples of where the backspace:

  • Searching: I would often navigate through documentation in a scanning manner by clicking the different links and then hitting backspace to return to the index to try another one. And I have see non-tech coworkers do the same when they are inspecting new subscribers.
  • Getting all the way back: I used google to search something, came on a Wikipedia page, followed quite a few articles (jumping in and out) and then I want to return to my original search query.

Came across this bug in passing.

I agree that generally, this is a good change. I think the simplest way to solve this:

We need to communicate it as well as possible so that users noticing the change can find out what happened and how to adjust preferences when needed.

is to add it to the Browsing section in about:preferences as something like "Use backspace to navigate between pages", and to make it a synced preference.

Prompting users who attempt to use the Backspace shortcut to tell them about the new shortcut seems bound to confuse most users prompted.

I 100% agree here, but amusingly, there is precedent for this in the Firefox UI in the caret browsing dialog that appears when pressing F7.

Depends on: 1685779
Depends on: 1685797

(In reply to Laurence "GreenReaper" Parry from comment #39)

I notice that Edge has a tooltip, "Click to go back (Alt+Left arrow), hold to see history". Firefox only has "Go back one page [/n] Right-click or pull down to show history" and does not mention a platform shortcut. Promoting Alt+Left/Right there (and appropriate alternatives on other platforms) could help those disadvantaged by this change.

I like that suggestion a lot! Both Edge and IE11 mention "Alt + Left arrow". Neither Chrome nor Safari do.

I filed bug 1685779 to update the new tooltip.

(In reply to wouterlindenhof from comment #43)

My primary reason for restoring it is that backspace is can be done with a single hand. While ALT+LEFT is actually ALT_LEFT+LEFT and doesn't support ALT_RIGHT+LEFT. So I would require two hands.

What OS are you using? Since you called the key "ALT" instead of "Command", I assume you're using Linux or Windows. I just tested ALT_RIGHT+LEFT on my Windows 10 laptop and it worked the same as ALT_LEFT+LEFT. Perhaps Linux reports ALT_LEFT and ALT_RIGHT keys differently? If that's the case, we should fix that!

(In reply to Asif Youssuff from comment #44)

We need to communicate it as well as possible so that users noticing the change can find out what happened and how to adjust preferences when needed.

is to add it to the Browsing section in about:preferences as something like "Use backspace to navigate between pages", and to make it a synced preference.

I like that suggestion. I just filed bug 1685797 to add a new preference checkbox.

(In reply to Chris Peterson [:cpeterson] from comment #45)

(In reply to wouterlindenhof from comment #43)

My primary reason for restoring it is that backspace is can be done with a single hand. While ALT+LEFT is actually ALT_LEFT+LEFT and doesn't support ALT_RIGHT+LEFT. So I would require two hands.

What OS are you using? Since you called the key "ALT" instead of "Command", I assume you're using Linux or Windows. I just tested ALT_RIGHT+LEFT on my Windows 10 laptop and it worked the same as ALT_LEFT+LEFT. Perhaps Linux reports ALT_LEFT and ALT_RIGHT keys differently? If that's the case, we should fix that!

It seems that the meaning of the RIGHT_ALT key changes depending on the locale of Windows.
In en-US it behaves similar to the left alt key.
In nl-NL (dutch, my default) it becomes an AltGr (alternate graphics) key.

For example pressing RIGHT_ALT+D in en-US results in focusing on the address bar but when my locale is nl-NL it results in typing ð and does NOT focusing on the address bar.
Another combo I tested is RIGHT_ALT+F4. In en-US it closes the active app (firefox, but also other apps like notepad.exe) while in nl-NL it has no effect.

I took at look at https://en.wikipedia.org/wiki/AltGr_key and it seems to only affect when the key represent a printable characters which it could be fixed (since left/right is non-printable), but since the behavior of RIGHT_ALT+F4 also changes depending on the locale I have strong doubts about requesting a fix.

This is another option to annoy veteran users, like a lot of other disputable choices in browser functionality over the past years (and don't play dumb, I'm sure you know which I'm talking about, but for those new around here, I could compile a list, but I don't feel like it right now). At the same time, novice users can very well be tought to use the backspace to go back. I don't see the big deal. Now we have to use, what Alt+Left? That requires two hands on a fullsize keyboard.

Please don't make browsers more complicated in an effort of trying to simplify it for newbies. Because it doesn't work like that. I can teach my mum to use the backspace to go back and she'll happily accept it. So what's the point in disabling it?

And don't give me that "you can always re-enable it in about:config" BS, because no novice user will know to look there, and many advanced users have to know in advance what to look for, once there.

Now, as for the fact that Backspace does a different thing when in a text field. Sure, that's normal, innit. But say for example the users thinks they're in a text field, but aren't. Then they'd go back a page by accident. Is that a problem? Yes. So the solution is not disable the bloody hotkey - that's HIDING THE PROBLEM AWAY. The solution is to not make it problematic to go back accidentally. Pressing forward should return to the page that's been gone back from, in the exact state in which it was left. No reloads, to cleared fields, javascript still in the exact same state.

Blocks: 1685995

(In reply to Martijn from comment #47)

The solution is to not make it problematic to go back accidentally. Pressing forward should return to the page that's been gone back from, in the exact state in which it was left. No reloads, [no] cleared fields, javascript still in the exact same state.

We already do this as much as is possible (it's called the "bfcache", or back-forward cache), but per web specifications, going back/forward in history is observable by the webpage (via beforeunload, unload, pageshow/pagehide and other events), and so webpages that do so (or that do other broken/user-hostile things) can and do still break. The fact is, the pre-patch behaviour leads to dataloss for a substantial number of users, there is no web-compatible way to make going back and forward completely side-effect-free, so on balance disabling the shortcut by default is the best thing for most of our users.

(In reply to wouterlindenhof from comment #46)

I took at look at https://en.wikipedia.org/wiki/AltGr_key and it seems to only affect when the key represent a printable characters which it could be fixed (since left/right is non-printable), but since the behavior of RIGHT_ALT+F4 also changes depending on the locale I have strong doubts about requesting a fix.

Going from doing nothing to doing something useful for a combination that is tricky to press accidentally seems worth considering, at least. I filed bug 1685995 for this.

Depends on: 1688016

🛑 Pascal, I cleared the relnote flag because this change will NOT ride the trains with Fx86. (I will be disabling or backing out the change for Fx86 in bug 1688016.) So we do NOT want the Fx86 release notes to say the Backspace shortcut has been removed.

I intend for this change to ride the trains with Fx87, so we will want Fx87's release notes to mention the shortcut removal.

(In reply to Romain Testard [:RT] from comment #31)

Joni, just pinging you here for awareness that this change will need documentation changes on https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly when it gets to release.

I am clearing the needinfo for Joni because I already updated the SUMO documentation about keyboard shortcuts.

relnote-firefox: ? → ---
Flags: needinfo?(jsavage)

Thanks for the heads up Chris, I removed this item from our 86 Beta relnotes.

Flags: needinfo?(pascalc)

[Tracking Requested - why for this release]:

FIREFOX 87 Release Note Request (optional, but appreciated)

This change originally landed in 86 Nightly, but I asked the new behavior to be preffed off in 86 Beta and Release. I didn't want this change to ride the trains until bug 1685779 added a keyboard shortcut hint to the back/forward toolbar buttons' and context menu items' tooltips. Bug 1685779 just landed in 87 Nightly and so I believe this change can ride to 87 Beta and Release.

[Why is this notable]: Disables a keyboard shortcut that has been around forever. Some users will be annoyed, so we should document the rationale for this change and how to re-enable to the old behavior.

[Affects Firefox for Android]: In theory yes, but not worth mentioning since few Android users will be navigating using a keyboard.

[Suggested wording]: To prevent user data loss when filling out forms, disable Backspace as a keyboard shortcut for "Go back one page" navigation. To re-enable the Backspace keyboard shortcut, change the about:config preference browser.backspace_action to 0.

[Links (documentation, blog post, etc)]: This Support article documents other Firefox keyboard shortcuts for "Go back one page" navigation, such as Alt or Command + Left Arrow: https://support.mozilla.org/kb/keyboard-shortcuts-perform-firefox-tasks-quickly

(In reply to Wouter Lindenhof from comment #46)

It seems that the meaning of the RIGHT_ALT key changes depending on the locale of Windows.
In en-US it behaves similar to the left alt key.
In nl-NL (dutch, my default) it becomes an AltGr (alternate graphics) key.

Various – mostly European – keyboard layouts have an Alt Gr key in place of the right Alt key, and the physical key is also labelled as such.

I have a really big and honest request/appeal/application/desire/wish.

I know that this change will not be canceled.

but can you please, like PLeASE, move the setting for this to the main Preferences menu?

that would be used, i assure you at 100%

thanks.

had you heard me?....

To re-enable the Backspace keyboard shortcut, you can change the about:config preference browser.backspace_action to 0.

QA Whiteboard: [qa-87b-p2]

(In reply to 07d66c1b47 from comment #55)

I have a really big and honest request/appeal/application/desire/wish.
...
but can you please, like PLeASE, move the setting for this to the main Preferences menu?

Ditto! This was quite a disappointing finding last night after updating to v87, particularly when one uses it regularly.

Use case: Sitting in the dark on the lounge, watching videos/movies, and need to return to a previous page to access a list of videos/movies returned from a previous search.

Scenario: I have a Mac Mini connected to my TV. I have the little DiNovo (https://support.logi.com/hc/en-au/articles/360025418953--Product-Gallery-diNovo-Mini) Bluetooth keyboard to control the Mac.

On the DiNovo is a touchpad that is also the arrow keys. However, in order to use the arrow keys there are two options, a physical switch to maintain the change to arrow keys. Second method, using the FN (Function) key combo to temporarily switch to arrow keys.

You can probable see where this is going but either way the interaction requires at least a three step process (Command + FN + Left arrow or Switch + Command + Arrow), but when using the physical switch it's a forth step as I have to switch it back. That's on a little keyboard with little keys, requiring two hands, in the dark and thus using the TV or turning on a light to see the keyboard.

As mentioned by others:

  • In my mind, adding the 'Leave page?' notification we so commonly see now would be a better solution for not only my given use case but for all use cases around preventing loss of partial form entries.
  • My assumption is editing the about:config is not so straightforward a process for a large segment of users.

Maybe changes such as these should be pointed out after updating FF so users can select if they want the change implemented or not???

Maybe changes such as these should be pointed out after updating FF

It is mentioned in the release notes. And the shortcut was added to the tooltip of the back button. And there is an option to change it back. It's really rare to be so lucky and you really expect even more? 🤔

so users can select if they want the change implemented or not???

Sure, they could do this. For this change and for every other change. This won't scale. Or do you really expect that all users have to answer 30 questions after every Firefox update? 🤔

(In reply to Sören Hentzschel from comment #58)

It is mentioned in the release notes. And the shortcut was added to the tooltip of the back button. And there is an option to change it back. It's really rare to be so lucky and you really expect even more? 🤔

Yes. My guess is the analytics on users who read release notes would be incredibly small. The tooltip is a moot point as how to do it is not the point. As I and others noted above, process to change it back is likely too advanced for most users.

Sure, they could do this. For this change and for every other change. This won't scale. Or do you really expect that all users have to answer 30 questions after every Firefox update? 🤔

No, I don't expect user to answer questions with every update but I do think it is reasonable to be offered the ability to tick a check box when significant UI changes have been implemented. Users were given a prompt when new privacy changes were implemented in past versions.

Yes. My guess is the analytics on users who read release notes would be incredibly small.

Everyone who is interested in new features and changes is responsible for informing themselves. If you see that something is different then, of course, the first thing to check are the release notes.

The tooltip is a moot point

The tooltip is not a "moot point" but relevant for users like you who used the old shortcut. Because the tooltip says how they can do the same as before (navigating back with the keyboard).

Users were given a prompt when new privacy changes were implemented in past versions.

This is not true at all. In the last few updates alone there were a lot of privacy improvements and also other improvements and there was never a prompt. That's why I said that you have to ask users 30 questions after every update if you reall want to prompt users for every small change. And this one is a really one change compared to all the big changes in every new major update. What you don't understand is that it's not only about this particular change. If you say that they should show a prompt for this small change this inevitably means they have to show prompts for a lot of other changes as well.

But really, these comments do no belong to Bugzilla. You should have this conversation on a appropriate mailing list. Bugzilla is a production tool for the developers and not meant for general discussions.

(In reply to Sören Hentzschel from comment #60)

Everyone who is interested in new features and changes is responsible for informing themselves. If you see that something is different then, of course, the first thing to check are the release notes.

Sorry for butting in, but... as much as I love reading release notes (and I feel sad whenever I see "Information not provided by developer" on my phone), it sure doesn't seem like it's obvious what's changed when the "Hi! You've been upgraded!" page pops up every few weeks in my Firefox.

Where can I see the release notes? If I go into Help > About Firefox and there click a tiny little link called What's New, then yeah, but that's not the page I'm greeted with, the update page is just a happy little page telling me I got updated. That's honestly not a good way to disperse information, especially not about some pretty substantial UX change. Maybe the release notes should be part of the browser (any kind of non-intrusive UI element that leads to the relnotes), or part of the update greeter page which honestly doesn't say much as it is right now.

(Small side note: the What's New site with the roughly five(!) items per desktop screen is amazingly unreadable. I'm aware that serving as few words per screen with as big a font as possible is the trend right now, but it was positively a chore to find the entry about the backspace as a first time reader)

So what do I want to say about this... I wonder just how many people there are out there who don't know there are relnotes at all and then blindly trip over a missing or "misconfigured" feature — can we really put the responsibility on the users to find out why something changed under them, as opposed to telling them that it changed or (which would be even better) will change?

I think that having a one-key shortcut is important for convenience and immediacy's sake, but I have also accidentally backed out of forms with Backspace on multiple occasions and agree that it's a problem worth solving. I think the ideal solution is to either have an "Are you sure?" prompt as Brian stated above or to use a less commonly typed key instead. The vertical line/backslash key would be a good contender since that would be typed much less often than Backspace while still being near the old shortcut. Using Alt+Left Arrow is functional, but somewhat awkward and not as immediate as a single key press.

Users shouldn't have to Google search to find some hidden setting to enable this feature. Nor should they have to bother with going through that process every time they reinstall Firefox on a new computer. I think having an "Are you sure?" popup (and possibly also using a less often used key) would fix both of these problems.

Leaving the secondary Alt+Left/Right Arrow shortcut enabled is a good decision to be consistent with other browsers, but another one key shortcut should exist alongside it, especially since the downsides of the previous Backspace implementation are wholly avoidable.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: