I'm trying to make an event handler for keyboard inputs while focused on a certain element of a webpage.
Two shortcuts I'm trying to detect are Ctrl+Shft+T and Ctrl+T. You may be aware that in Firefox and Chrome these are shortcuts for "reopen closed tab" and "new tab". I have the following test code:
<script>
var i = document.createElement("input");
i.addEventListener('keydown', function(event) {
event.preventDefault();
});
document.body.appendChild(i);
</script>In both Firefox and Chrome, preventDefault() works for Ctrl+Shft+T but not for Ctrl+T (edit: Ctrl-Shft-T does appear to not work either in Chrome but certain shortcuts liks Ctrl+J are prevented). I thought that maybe it had to do with Ctrl being pushed before T, but Shft+Ctrl+T is also overrode correctly.
I tried watching for the keypress event as well but that didn't work either.
Is there a way to suppress opening a new tab behavior, or should I propose a different shortcut?
I asked in the Chromium IRC and was told that certain keyboard-shortcuts were protected by the browser and cannot be overridden by javascript.
[16:50:44] <mimi> hi, would anyone know why certain keyboard shortcuts can be overriden in javascript using preventDefault(), but others not? For example, I can prevent it from opening downloads with Ctrl+J but I can't prevent it from opening a new tab with Ctrl+T
[16:53:09] <jbroman> mimi: I couldn't tell you the exact logic for individual shortcuts, but browsers tend to protect certain shortcuts so that users can still do things like close tabs even if an application tries to prevent it, and so that the user isn't surprised by not being able to control the browser.
[16:53:35] <jbroman> I suspect, therefore, that it's not a bug but an intentional UI choice.
[16:54:16] <mimi> that is quite likely, I observed the same behavior with Firefox, except some shortcuts behave differently of course
[16:55:14] <ellyjones> there is no actual central logic to that choice
[16:55:23] <ellyjones> we decided case-by-case which shortcuts should/shouldn't be override-able
[16:55:39] <mimi> is there a list available anywhere?
[17:00:12] <jbroman> not that I'm aware of, sorry
[17:00:29] <ellyjones> unfortunately I don't think so
[17:00:52] <mimi> well thanks for clearing it up at least
[17:00:53] <ellyjones> the logic for whether something is high priority or not is kinda scattered around the codebase, and may depend on the platform (eg, on Mac I think you can grab ctrl-w, because cmd-w is close tab there)
[17:02:13] <ellyjones> one of my team's planned projects for this year is to bring some sort of order to this specific piece of chaos
[17:05:09] <jbroman> mimi: one such place appears to be https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/ui/browser_command_controller.cc;l=264;drc=a393fe54c419b9583dc37d1d0d6df8e5e6b0bf37;bpv=0;bpt=1 but I don't know this code very well
[17:05:22] <jbroman> (and even there you have to map back from those commands and other logic to the corresponding shortcuts)
[17:05:27] <mimi> that's gonna be well appreciated, because I could not find documentation on the subject anywhere for either chromium or firefox, and it would be a good help for webapp design
[17:05:33] <ellyjones> jbroman: that is one of the places, yeah
[17:05:45] <ellyjones> also any place you see AcceleratorManager::kPriorityHigh
It's fair to assume the behavior is similar in Firefox. I haven't found any official list of protected key commands for either browsers.
To answer the question: No, you cannot override protected keyboard inputs with preventDefault or any means I know of.