The default value for permissions.default.shortcuts is 0, which allows webpages to override Firefox's normal response to keyboard shortcuts. For example, Ctrl-R will normally reload the page, but if permissions.default.shortcuts = 0, then Outlook Web Access will instead interpret Ctrl-R as "Reply to this message."

When this default is left alone, the Backspace and Delete buttons work as expected, both in the URL and Search bars, and in text input fields on web pages: Backspace deletes the character to the left of the text cursor, and Delete deletes the character to the right of the text cursor.

Setting permissions.default.shortcuts = 2 blocks sites from overriding keyboard shortcuts, so that (for example) Ctrl-R will consistently reload the current page, regardless of what that page is. (This can also be done on a per-site basis.) But it also has a weird side effect: The Delete button continues to work when used in the URL and search bars, but does nothing when used in a text input field. There is no crash or aberrant behavior; the text is simply left unchanged.

In Firefox 66.0.3 and later, Backspace continues to function normally. In Firefox 66.0.1 and earlier, in contrast, Backspace is broken worse than Delete is (details at the end).

Note: The accepted answer now contains a (partial) solution, and the rest of this question is mostly information that I provided in an attempt to help someone else figure out what was wrong and how to fix it. So if you are reading this question because you are experiencing this problem yourself and need a solution, you can probably skip down to the accepted answer from here, and only read the rest of the question if that fails to solve your problem, or if you're curious.

Possibly related: Mozilla's list of Keyboard Shortcuts (https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly) includes, in the "Editing" section, the entry:

Command     Shortcut
Delete      Del

I have no idea how that can possibly be considered a "shortcut," as opposed to normal text entry (notably, Backspace is not listed as a "shortcut" in the editing section), nor why not allowing sites to "override" it should result in nothing at all happening, rather than something being deleted. But the listing of Del/Delete as a keyboard shortcut seems like a possible link between cause (not allowing sites to override keyboard shortcuts) and effect (Delete not working in text input fields, on websites).

I have also verified that it is not necessary to have a site actually try to override anything (at all) to observe this bug; the following HTML is sufficient (both to have Delete work as expected if permissions.default.shortcuts = 0, and to have it do nothing if permissions.default.shortcuts = 2):

<!DOCTYPE html>

Text box: <input type="text">


This behavior is also consistent across numerous actual websites (I've confirmed Stack Exchange, Google, and my university's Outlook Web App email page), and I have not observed any websites on which it does not occur. It occurs regardless of whether I use the delete button on my laptop's built-in keyboard or my USB keyboard.

Finally, I observed the following results at the Javascript Key Event Tester (https://unixpapa.com/js/testkey.html) (nothing suppressed, all attribute values shown, text input box focused prior to typing): Backspace gives:

keydown  keyCode=8         which=8         charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=Backspace char=undefined location=0 repeat=false
         keyIdentifier=undefined keyLocation=undefinedkeyup    keyCode=8         which=8         charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=Backspace char=undefined location=0 repeat=false
         keyIdentifier=undefined keyLocation=undefined

regardless of the value of permissions.default.shortcuts (or browser.backspace_action, for those reading the fine print below). Splitting the conjoined line (presumably due to the backspace being applied to a carriage return), and omitting the attributes that turn out to be the same for all of these tests, gives:

keydown  keyCode=8         which=8
keyup    keyCode=8         which=8

In contrast, pressing Delete gives

keydown  keyCode=46  (.)   which=46  (.)
keyup    keyCode=46  (.)   which=46  (.)

if permissions.default.shortcuts = 0 (i.e., when Delete works as expected), but only

keyup    keyCode=46  (.)   which=46  (.)

if permissions.default.shortcuts = 2 (i.e., when Delete does nothing in text input fields). That is, the keyup is present, but the keydown is missing. (Which is bizarre.)

So, my central question is: How do I keep websites from overriding actual Firefox keyboard shortcuts, that actually do something, without breaking Delete?

A few technical details on my system (I can supply more if that is useful, although the fact that I obtained similar (or worse) results on two other (library) computers suggests that this is probably not system- or hardware-specific): I am using Firefox 71.0 (64-bit), on Ubuntu (18.04.1), on a Dell Precision 5540 laptop (i7-9750H). My external keyboard is a Microsoft Natural Ergonomic Keyboard 4000, for which I have not installed any special software, nor have I remapped any keys.

cat /etc/default/keyboard gives


# Consult the keyboard(5) manual page.



How Backspace is also (and extra-) broken in 66.0.1 and earlier: What happens if you press Backspace without focusing a text input field is controlled by browser.backspace_action. 0 (the default on Windows) indicates "navigate to the previous page," 1 indicates "scroll up," and 2 indicates "do nothing."

However, in versions of Firefox before 66.0.2 or 66.0.3 (I'm not sure which), setting permissions.default.shortcuts = 2 makes Backspace behave the same regardless of whether a text input field is focused.

So if browser.backspace_action is set to 2, pressing Backspace is just as broken as Delete is, but no more. If browser.backspace_action is set to 1, it's only marginally worse; the page will jump up unexpectedly, but nothing else will happen. But if it's set to 0 (which is, again, the Windows default!), pressing Backspace, even with a text input box focused, will leave the page to return to the previous one!

(I initially believed the Backspace problem to be Windows-specific, because I observed it on (university library) computers running Windows and Firefox 66.0.1, but not on (university library) computers running MacOS and Firefox 66.0.3 (nor on my own computer, running Linux and Firefox 77.0.1). But it turns out that that difference of two minor versions happens to encompass when someone at Mozilla patched the code to fix that bug as it applied to Backspace, but neglected to do the some for it as it applied (more mildly) to Delete.)


1 Answer 1


The immediate solution is to build Firefox from source, after applying the patch (for the current stable release, 71.0.1, although it should be the same for many versions back (at least to 66.0.x, and likely further), apart from differences in line numbering and hashes):

diff --git a/browser/base/content/browser-sets.inc b/browser/base/content/browser-sets.inc
index c90f3aa340..ffd8727350 100644
--- a/browser/base/content/browser-sets.inc
+++ b/browser/base/content/browser-sets.inc
@@ -180,7 +180,7 @@
     <key id="key_paste"
-    <key id="key_delete" keycode="VK_DELETE" command="cmd_delete"/>
+    <key id="key_delete" keycode="VK_DELETE" command="cmd_delete" reserved="false"/>
     <key id="key_selectAll" key="&selectAllCmd.key;" modifiers="accel"/>

     <key keycode="VK_BACK" command="cmd_handleBackspace" reserved="false"/>

For anyone who doesn't speak diff, that means: after modifying the file browser/base/content/browser-sets.inc to replace the line

<key id="key_delete" keycode="VK_DELETE" command="cmd_delete"/>


<key id="key_delete" keycode="VK_DELETE" command="cmd_delete" reserved="false"/>

As indicated in https://bugzilla.mozilla.org/show_bug.cgi?id=1445942, an analogous problem used to exist for Backspace as well, and was fixed in some sub-version of Firefox 66. Thus, the "Windows-only" problem I observed was actually not operating-system specific, but a result of the version of Firefox that my university library has on its Windows machines (66.0.1) being slightly behind the version on its Macs (66.0.3), and well behind the version on my own, Linux computer (71.0.1).

I have submitted a new bug to Bugzilla, https://bugzilla.mozilla.org/show_bug.cgi?id=1604970, with the patch above. So, hopefully, the answer to this question will soon be simply "Upgrade Firefox."

Even when that happens, though, I'm planning to leave this question (and answer) up, so that anyone stuck with an older version of Firefox who stumbles on it can benefit. Because this is a relatively simple (if rather CPU time--consuming), but hardly intuitive, solution to an obnoxious problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .