New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot bind to ctrl-n #53

Open
technomancy opened this Issue Sep 26, 2017 · 11 comments

Comments

Projects
None yet
5 participants
@technomancy

technomancy commented Sep 26, 2017

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 comment has been minimized.

Show comment
Hide comment
@eejdoowad

eejdoowad Sep 26, 2017

Member

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.

Member

eejdoowad commented Sep 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@technomancy

technomancy Sep 26, 2017

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.

technomancy commented Sep 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@aidalgol

aidalgol Sep 26, 2017

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.)

aidalgol commented Sep 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@eejdoowad

eejdoowad Sep 26, 2017

Member

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.

Member

eejdoowad commented Sep 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tromey

tromey Sep 28, 2017

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

tromey commented Sep 28, 2017

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

@eejdoowad

This comment has been minimized.

Show comment
Hide comment
@tromey

This comment has been minimized.

Show comment
Hide comment
@tromey

tromey commented Sep 28, 2017

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

@Hi-Angel

This comment has been minimized.

Show comment
Hide comment
@Hi-Angel

Hi-Angel Sep 28, 2017

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.

Hi-Angel commented Sep 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@eejdoowad

eejdoowad Sep 29, 2017

Member

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

Member

eejdoowad commented Sep 29, 2017

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

@technomancy

This comment has been minimized.

Show comment
Hide comment
@technomancy

technomancy Oct 11, 2017

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.

technomancy commented Oct 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@eejdoowad

eejdoowad Oct 12, 2017

Member

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

Member

eejdoowad commented Oct 12, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment