The default value for
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
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.
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
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> <html> <body> Text box: <input type="text"> </body> </html>
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.
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
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 key=Backspace keyup keyCode=8 which=8 key=Backspace
In contrast, pressing
keydown keyCode=46 (.) which=46 (.) key=Delete keyup keyCode=46 (.) which=46 (.) key=Delete
permissions.default.shortcuts = 0 (i.e., when
Delete works as expected), but only
keyup keyCode=46 (.) which=46 (.) key=Delete
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
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
# KEYBOARD CONFIGURATION FILE # Consult the keyboard(5) manual page. XKBMODEL="pc105" XKBLAYOUT="us" XKBVARIANT="" XKBOPTIONS="" BACKSPACE="guess"
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
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.
browser.backspace_action is set to
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