Open Bug 1481311 Opened 6 years ago Updated 9 months ago

Hitting Backspace can make Firefox switch to a previous page

Categories

(Firefox :: Keyboard Navigation, defect, P2)

Product:
Firefox
Component:
Keyboard Navigation
Version:
61 Branch
Type:
defect

Tracking

()

People

(Reporter: erwinm, Unassigned)

References

Details

Attachments

(1 obsolete file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180704003137 Steps to reproduce: I tried to paste some text, then delete part of that text. Actual results: I ended up in a previous page. Expected results: If we can't paste and delete for whatever reason, users shouldn't be knocked back to another page. I have coordination problems, so I can't watch the screen when I'm using the keyboard.
P.S. I see that a hidden about:config pref allows users to turn the thing off.
(In reply to MarjaE from comment #1) > P.S. I see that a hidden about:config pref allows users to turn the thing > off. You must be referring to browser.backspace_action. Considering this and bug 108816, comment 54, I'm correcting the summary. (In reply to MarjaE from comment #0) > Steps to reproduce: > > I tried to paste some text, then delete part of that text. More detailed steps to reproduce are needed. What page where you on, and what element had focus? If focus wasn't on a text field, then it's intended behavior for the Backspace key to act like the Back button.
Component: Untriaged → Keyboard: Navigation
Product: Firefox → Core
Summary: Hitting delete can make Firefox switch to a previous page → Hitting Backspace can make Firefox switch to a previous page
"What page where you on, and what element had focus?" Tumblr. I thought the focus was in the text field where I'd pasted. I was busy typing, so I couldn't watch the screen. "then it's intended behavior for the Backspace key to act like the Back button." ... Maybe that works for you, if you can type, and can watch the screen, at the same time. But it can cause trouble for those of us who can't.
I don't like the default Windows behavior for this, but I don't get to make that decision. surkov, given the accessibility implications, should we revisit the decision made in bug 108816 to have this behavior by default on Windows?
Flags: needinfo?(surkov.alexander)
Priority: -- → P5
(In reply to Henri Sivonen (:hsivonen) from comment #4) > surkov, given the accessibility implications, should we revisit the decision > made in bug 108816 to have this behavior by default on Windows? N.B.: reporter is using Mac OS. A case can be made to bring Mac OS in line with Linux. The feature exists for the sake of Internet Explorer parity, a browser that was last available on Mac OS back in 2003. https://dxr.mozilla.org/mozilla-release/source/browser/app/profile/firefox.js#759
It appears that suggestion from bug 108816, comment 54 can be a good way to keep the existing shortcut working and resolve the accessibility issue. Another way to address the issue I think could be a confirmation dialog, which is shown, if the user has typed anything on a web page, and when the user hits backspace and thus is about to leave the web page.
Flags: needinfo?(surkov.alexander)
Status: UNCONFIRMED → NEW
Ever confirmed: true

At this point, per bug 108816 comment 57 neither (pre-Chromium) Edge nor Chrome do this, so I think we should stop too. This is causing significant user confusion and dataloss, so we should probably reprioritize as well...

Markus, I'm told making this call would be in your wheelhouse. Could you take a look, please?

Flags: needinfo?(mjaritz)
Priority: P5 → --

I fully agree with changing this shortcut behavior. The problems outweigh the benefits clearly as bug 108816 comment 57 describes.

What I am not clear about is if we need to provide an alternate shortcut to navigate back, and what that should be.
How would one naviate back using the keyboard without this shortcut? Maybe Shift-Backspace or similar might work, if needed.

(I do not think making the shortcut conditional on previous typing on the page is a good way to go, as this will not be apparent to the user, and add complexity to the behavior. Using a dialog will would also add some of that uncertainty on when it will show, and when not; and will interrupt peoples workflow - be it typing, or navigating back, as both would be blocked by it.)

Flags: needinfo?(mjaritz)

Shift-Backspace is currently mapped to Forward, so it would be confusing to change that to Back.
Ctrl-Backspace doesn't seem to be mapped.

Back is already mapped to Alt + Left Arrow, but that's quite an awkward shortcut and can't be typed with one hand. Alt Gr + Left Arrow isn't mapped. Ctrl + Left Arrow would be easy to press.

On Mac, Cmd+Left is quite easy to press with one hand (using the right-hand Cmd key) and maps to "back".

On Windows, using right-Alt + Left-arrow should work, right?

I guess some keyboards have Alt Gr instead of right-Alt. We should consider making Alt Gr + left arrow Just Work, no?

Flags: needinfo?(mjaritz)

I've never come across a keyboard with a right-Alt key, only Alt-GR, but that may be due to my locale (UK).

I agree adding support for Alt Gr + Left would be a good option. It's easy enough to press and people already know about Alt + Left.

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #10)

On Mac, Cmd+Left is quite easy to press with one hand (using the right-hand Cmd key) and maps to "back".

On Windows, using right-Alt + Left-arrow should work, right?

I guess some keyboards have Alt Gr instead of right-Alt. We should consider making Alt Gr + left arrow Just Work, no?

Sounds good.

Flags: needinfo?(mjaritz)

OK. So looks like neither Edge nor Chrome support Shift+Backspace; I would argue we drop that too.

It looks like on Windows the relevant bits in browser-sets.inc are:

<key id="goBackKb"  keycode="VK_LEFT" command="Browser:Back" modifiers="alt"/>
<key id="goForwardKb"  keycode="VK_RIGHT" command="Browser:Forward" modifiers="alt"/>

and I'm a little surprised that "alt" here does not include Alt Gr. Maybe it just should. Masayuki, do you know anything about that end of things?

Flags: needinfo?(masayuki)

Some keyboards (such as what I am using) do not have right-Alt at all. Nor Alt-Gr. So it is really inconvinient to press Alt+Left for me.

But I'm fine with this change as long as browser.backspace_action is left.

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #13)

OK. So looks like neither Edge nor Chrome support Shift+Backspace; I would argue we drop that too.

It looks like on Windows the relevant bits in browser-sets.inc are:

<key id="goBackKb"  keycode="VK_LEFT" command="Browser:Back" modifiers="alt"/>
<key id="goForwardKb"  keycode="VK_RIGHT" command="Browser:Forward" modifiers="alt"/>

and I'm a little surprised that "alt" here does not include Alt Gr. Maybe it just should. Masayuki, do you know anything about that end of things?

If we treated AltGr exactly same as AltRight, some shortcut keys would work unexpectedly. E.g., if there is a shortcut key, Alt + A and AltGr + A produces a character on active keyboard layout. So, we shouldn't do such change.

On the other hand, it really sounds reasonable to map AltGr + LeftArrow to Browser:Back. So, I'd recommend that we/d make modifiers attribute of key element take "altgraph" value and add another key element for AltGr + LeftArrow.

Flags: needinfo?(masayuki)

(In reply to Masatoshi Kimura [:emk] from comment #14)

Some keyboards (such as what I am using) do not have right-Alt at all. Nor Alt-Gr. So it is really inconvinient to press Alt+Left for me.

Indeed. I don't know about other region's physical keyboards though, at least in Japan, there are a lot of notebook PCs which do not have AltRight key because PC vendors do not have enough space to put all keys of 106 keyboard due to a lot of IME specific keys.

Anyway, I bet we'll get a lot of complaints if we disable Backspace key for Browser:Back by default.

How about to map Backspace and Shift + Backspace to a function which shows dialog to confirm whether executing Browser:Back or Browser:Forward like when you type F7? Then, users who don't like these shortcut key mappings can disable them from the dialog easier than using about:config.

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #17)

Anyway, I bet we'll get a lot of complaints if we disable Backspace key for Browser:Back by default.

I also wonder if we should get telemetry data for better understanding of the usage before really disabling it.

How about to map Backspace and Shift + Backspace to a function which shows dialog to confirm whether executing Browser:Back or Browser:Forward like when you type F7? Then, users who don't like these shortcut key mappings can disable them from the dialog easier than using about:config.

Hi Markus,
What do you think about Masayuki's idea? Thanks!

Flags: needinfo?(mjaritz)

Anyway, I bet we'll get a lot of complaints if we disable Backspace key for Browser:Back by default.

I also wonder if we should get telemetry data for better understanding of the usage before really disabling it.

If we have reasonable worry that this might be broadly used and change will cause a lot of problems, we might want to do that.
(I do not think this is the case, esp. as we would only align with a behavior known from other browsers.)

How about to map Backspace and Shift + Backspace to a function which shows dialog to confirm whether executing Browser:Back or Browser:Forward like when you type F7? Then, users who don't like these shortcut key mappings can disable them from the dialog easier than using about:config.

Making each user decide, because we can not find an acceptable solution is not a good way to go. This is something we should consider if a very large portions of our users would want different behaviors, not necessarily when we talk about a very small subsets.

Flags: needinfo?(mjaritz)
Priority: -- → P2
Component: Keyboard: Navigation → User events and focus handling

Being stuck at home due to the pandemic, there is a lot more being done in web browser forms that ever before and having sometimes half an hour or more of work disappear because backspace is being interpreted as a back command is no longer tenable. Some places (on a site by site basis) have implemented a popup to prevent you from losing the text you have entered, but this is not universal.

The backspace key has been overloaded in such a way as to break many web applications. I realize this is a holdover from early IE, but it is long past the time when having this particular behavior is interacting badly with long-form text entry and applications on the internet (specifically those that break if you use the browser back). Since the back action is so potentially destructive, it needs to have an unambiguous activation criteria, one that is not overloaded with an action that you will often use exactly when you do not want to use back.

At the very least, this setting needs to be transparent to the user, not buried in about:config where many people don't even realize the setting exists. Ideally, the user should be asked about it during setup.

The suggestion above of making a universal and default-on popup that prompts the user to confirm they mean to leave a page with uncommitted text would also be helpful. Some pages implement this themselves, but as it is not a universal feature many do not.

How do we make progress on this? I don't understand why alt (the left one) plus left arrow isn't good enough. On mainstream keyboards, it seems to fit perfectly the ergonomic guidance that you're supposed to press the modifier with a different hand than the key being modified, so left hand for alt and right hand for left arrow should work. (I'm aware that there are ergonomic keyboards that put "left" alt and the left arrow on the same side of the keyboard.)

Flags: needinfo?(masayuki)

I don't know who is handling this...

I wonder, Alt + ArrowLeft is also annoying shortcut if they use Linux or macOS and they (or their environment) map caret move or something to Alt + ArrowLeft because our widget prefers it in editor, but won't disable it when non-editable element has focus. So, I think that the safest approach here must be just disabling the Backspace key shortcut.

Flags: needinfo?(masayuki)

(And I don't know how to count "expected" page navigation by Backspace with telemetry probes.)

So, I think that the safest approach here must be just disabling the Backspace key shortcut.

Let's do that. It's fairly obvious that Backspace is a problem, and, as you say, we wouldn't know how to make a telemetry-based decision.

And the Backspace as history navigation is handled by browser/. So, out of scope of this component about that.
https://searchfox.org/mozilla-central/rev/3d39d3b7dd1b2be30692d4541ea681614e34c786/browser/base/content/browser.js#2765-2785

Component: DOM: UI Events & Focus Handling → Keyboard Navigation
Product: Core → Firefox
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED

"On mainstream keyboards, it seems to fit perfectly the ergonomic guidance that you're supposed to press the modifier with a different hand than the key being modified"

That would be an accessibility barrier, especially if they can't be hit with the same hand, or are in awkward positions. Yes, sticky keys exist, but jumping across the keyboard increases the error rate and can worsen rsi.

Attachment #9158504 - Attachment is obsolete: true

To make progress on this, please address the review comments about telemetry at https://phabricator.services.mozilla.com/D80637

Assignee: hsivonen → nobody
Status: ASSIGNED → NEW
Depends on: 1041377
Severity: normal → S3

It looks like this is resolved in release 87 via disabling the backspace shortcut. https://www.mozilla.org/en-US/firefox/87.0/releasenotes#note-788542

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

Attachment

General

Creator:
Created:
Updated:
Size: