Cannot bind to ctrl-n

[technomancy]

When I try to set a key binding to ctrl-n it opens a new window instead of changing the binding.

Edit: this is not just a bug in the UI to set the binding; editing the underlying storage.js file to make ctrl-n a binding has no effect; this is likely a bug in Firefox.

[eejdoowad]

This isn't a bug. It's intended behavior (trust me, I've checked). It's possible to prevent the default action of most built-in keyboard shortcuts by calling preventDefault() on the generated DOM event. Unfortunately, there are a few that can't be stopped. The wisdom behind this design is that it prevents rogue websites from hijacking shortcuts that users expect to always work.

Unfortunately, your only option is to pick a different keyboard shortcut. Perhaps at some point in the future Firefox will devise a more powerful web extensions keyboard API. Until then, we have to live with the limitations of DOM event processing.

[technomancy]

Thanks for the confirmation; I guess I'll stick with the stable Firefox for now and hope that the FF devs come to their senses before it's discontinued. It's bizarre that they chose this particular binding as sacrosanct; I can't remember the last time I opened a new window on purpose.

[aidalgol]

The wisdom behind this design is that it prevents rogue websites from hijacking shortcuts that users expect to always work.

That makes sense, but why can extensions not do it? (Sorry for going on a bit of a tangent.)

[eejdoowad]

Saka Key relies on adding JavaScript DOM event listeners (e.g. window.addEventListener('keydown', doSomethingInteresting)) to intercept keyboard events. These are the same type of event listeners websites use to make their pages interactive. Because Saka Key uses the same API, it inherits the limitations of the API.

Firefox itself has to be changed to work around this limitation. One possibility is to change how existing APIs work when called from an extension. An example of this is document.execCommand('paste') can be called from any page, but only actually pastes data if called from a web extension with the "clipboardRead" permission. In our case, Firefox could modify how event.preventDefault() behaves when called from a web extension.

Another possibility is to introduce a completely new keyboard API available only to web extensions.

Until then, people expect their software to work today. Saka Key makes a compromise based on what's possible.

[tromey]

Is there a bug in Mozilla's bugzilla about this?

[eejdoowad]

https://bugzilla.mozilla.org/show_bug.cgi?id=380637

[tromey]

https://bugzilla.mozilla.org/show_bug.cgi?id=1320332 seems a bit more targeted.

[Hi-Angel]

Just a crazy idea for workaround: may be there's a way to edit some Firefox config to disable all browser shortcuts, thus making them possible to get rebound?

I am not using specifically Saka Key (not yet), but as I understand it's very much like the old XUL-dependent Pentadactyl which I am yet using, and as far as I remember I didn't have to use original Firefox shortcuts for 1.5 years, since I found the addon.

[eejdoowad]

@Hi-Angel, if you ever find the config you describe, please share.

[technomancy]

I found this (somewhat drastic but very satisfying) solution to the problem by replacing my window manager with something that can intercept keys as they are typed based on which application has focus: https://github.com/ch11ng/exwm/wiki#simulation-keys

Doesn't fix the underlying problem, but I'm much less frustrated now.

[eejdoowad]

Drastic measures indeed. Hopefully something comes of these API proposals sooner rather than later.
https://bugzilla.mozilla.org/show_bug.cgi?id=1215061#c60
https://github.com/cmcaine/keyboard-api