Feature request. More granular Extension's hotkeys scope

[InsaneDoggo]

Would be nice to be able to limit hotkey' scope (i.e. where it can be triggered).

Example: (chrome-related terminology) I'm using "chrome.commands" API to control embedded player via "content scripts", to seek forward/backward by Ctrl + Left/Right arrow keys to be precise. This extension is supposed to work on specific URL. Arrows is very convenient and intuitive keys for mentioned player's actions so I don't want to use some weird/complex shortcut combos, at the same time I don't want those hotkeys to override my usual "browser experience" on other tabs/URLs e.g. while typing in search bar etc.

Possible solutions:

1. Config in Manifest to limit scope to "active tab" + [optional] match specific URLs e.g. https://foo.bar/
2. Provide API to invoke default implementation. e.g. as an extra callable parameter in "chrome.commands.onCommand.addListener".

[oliverdunk]

Related Chromium issue: https://issues.chromium.org/issues/364821285

[hanguokai]

If you use the content script to control the shortcut behavior on the active tab, besides browser.commands, you can also use Web page shortcut methods, e.g. document or element (player in your example) .addEventListener("keydown", listener), which supports arrow keys.

[InsaneDoggo]

@hanguokai yeah, it's one of the workarounds, although Extension's shortcuts is more convenient, e.g. chrome has dedicated "all shortcuts page" to be managed by user. Also IIRC "keydown approach" requires element/iframe to be in focus, which may be not intended behavior.

Moreover case with player is just an example, I believe there are more use cases for "hotkey scopes" feature. No to mention that "foo.bar site companion" is very popular type of extensions. We already has option to limit extension's access to page's content by URL patterns, which improves User's trust. So it feels natural that other browser' features also would support scopes.

[xeenon]

Do you need the page to have keyboard focus or are you looking for the commands to be app global still?

[InsaneDoggo]

@xeenon well, it depends, e.g. in future I may decide to support "Picture in Picture" mode which is beyond "page-only" scope. I would prefer to not focus on my specific case. I can describe my vision on this issue, consider following scenarios:

1. Global shortcuts (already implemented)
2. Scope limited to "active/focused tab" + some "static filters/patterns" defined in manifest. Browser should be able to decide on it's own whether to call user's handlers. (not implemented)
3. Global + advanced filtering: user's code decides whether to handle/consume shortcut event. (not implemented)
   3.1. by returning true/false (isConsumed)
   3.2. by invokable argument defaultHandler()
   Note: command handler's "ability to answer" may be limited to current frame/tick and "service.js" environment. Developers can maintain some state inside service.js so they can always decide about "consuming" shortcut event.

[Rob--W]

This topic was discussed at yesterday's WECG meeting, with the notes recorded at https://github.com/w3c/webextensions/blob/main/_minutes/2024-09-12-wecg.md#meeting-notes.

During the meeting, a suggestion was raised to allow restriction of shortcuts to specific contexts, but still reserve the shortcut. That doesn't seem to solve your feature request, where the primary goal is to allow others to use the shortcut if the extension does not use it.

Currently, extensions (and web pages) that want to handle shortcuts can intercept them from a content script or an extension document. In a comment above (#683 (comment)), you expressed that you don't want to use it because the commands API has some integration in browser UI (shortcut management page).

While the browser would be in a better position than extensions to resolve conflicts with multiple shortcut registrations, it lacks any context to offer a good resolution. During the meeting, concerns were raised about the complexity of implementing the requested capability.

It would be nice to have a standardized way to handle the behavior when multiple extensions register the same shortcut. The current behavior pretty much boils down to "whoever registered the shortcut first wins", which can also cause confusion, e.g. a recent bug report in Firefox is at https://bugzilla.mozilla.org/show_bug.cgi?id=1911798.

[rdcronin]

This was discussed at TPAC. In general, we concluded that this wasn't something we were interested in pursuing. While we can see the utility in it, we don't think it would be something that we could a) structure in a way that provided the right behavior for all developer use-cases b) determine effective UI for users to be able to audit and understand the scope of these shortcuts, nor c) see widespread usage or adoption. Additionally, the majority of the use cases for tab-specific scoped hotkeys also require doing something in the tab, which provides the alternative of installing listeners for certain keys directly within the DOM. We understand this isn't as robust a solution as having it mediated by the browser (since it wouldn't work for cases where the tab wasn't focused), but we didn't feel this was a sufficient differentiator to pursue this.

Inline with this, I'm unfortunately going to close this issue out. But thank you very much for filing the issue and for the good discussion it led to!