You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some web apps use shortcuts that may conflict with standard Firefox shortcuts for their functionalities. To use such shortcuts, users need to disable them in the app browser settings.
One such shortcut is Ctrl+W. Since it is often used by Firefox users to close the tab (or window), it should be enabled by default. However, other users might expect that web apps can automatically handle it themselves without needing to disable it in the app browser settings (#443), so neither enabling nor disabling it by default is a perfect solution.
Proposed Solution
There should be an option to let websites handle such shortcuts themselves if they want but keep the normal Firefox behavior otherwise.
This might then become a default option for specific keyboard shortcuts. This way, shortcuts like Ctrl+W will still normally be handled by Firefox to close the tab, but websites will also be allowed to provide a custom handler for their functionalities, without needing to change the browser settings.
This should still be an option, because some users might want that Ctrl+W to always close the tab, even if the website provides a custom handler.
Additional Information
This can be probably done by setting reserved="false" on the key element.
Currently, shortcuts that can be disabled are close tab (Ctrl+W), close window (Ctrl+Shift+W), quit application (Ctrl+Shift+Q) and private browsing (Ctrl+Shift+P). It might be useful to expand these options to more shortcuts, in case there are other shortcuts that web apps commonly use that conflict with built-in Firefox shortcuts.
Additionally, it still needs to be considered which of the shortcuts will have this new option enabled by default, and which will remain reserved by default.
Another thing to consider is how to implement settings UI for this. Possibly the easiest option is to add another list, similar to the existing shortcuts list, that determines just if a specific shortcut is reserved. However, this may be quite long if more shortcuts are added and possibly confusing to users (since the reserved part would not have an effect if the shortcut is completely disabled). A better option is to add some kind of three-way switch for each shortcut that determines if the shortcut is disabled, unreserved or reserved.
The text was updated successfully, but these errors were encountered:
I am trying to run Home Assistant Code Server in a Firefox PWA but this is apllicable to Code Server itself in a Firefox PWA.
In Chrome / Edge the webpage with Code Server takes control over keyboard shortcuts and the webpage is a tabbed interface so Ctrl W, Ctrl Tab and Ctrl Shift Tab amongst many other shortcuts gets interpreted by the webpage rather than the browser.
In Firefox PWA only with Ctrl W disabled in settings does it get passed to the webpage. There is no setting to disable Ctrl Tab and Ctrl Shift Tab. I have tried tinkering and writing a userChrome.js file as well as editing the config file to no avail, but it might be due to wrong configuration on my end.
Are there instructions to manually disable certain keyboard shortcuts / pass them on to the webpage until this feature gets implemented. Right now usability on my end is non-existent w/o ability to switch tabs.
You can probably apply a custom userChrome.js file to the web app profile that removes specific shortcuts. I'm currently not sure what exactly you need to do, but basically, the script would need to be loaded when the window is opened and remove/disable the shortcut element. You can check the list of some shortcuts here.
Problem Description
Some web apps use shortcuts that may conflict with standard Firefox shortcuts for their functionalities. To use such shortcuts, users need to disable them in the app browser settings.
One such shortcut is
Ctrl+W
. Since it is often used by Firefox users to close the tab (or window), it should be enabled by default. However, other users might expect that web apps can automatically handle it themselves without needing to disable it in the app browser settings (#443), so neither enabling nor disabling it by default is a perfect solution.Proposed Solution
There should be an option to let websites handle such shortcuts themselves if they want but keep the normal Firefox behavior otherwise.
This might then become a default option for specific keyboard shortcuts. This way, shortcuts like
Ctrl+W
will still normally be handled by Firefox to close the tab, but websites will also be allowed to provide a custom handler for their functionalities, without needing to change the browser settings.This should still be an option, because some users might want that
Ctrl+W
to always close the tab, even if the website provides a custom handler.Additional Information
This can be probably done by setting
reserved="false"
on thekey
element.Currently, shortcuts that can be disabled are close tab (
Ctrl+W
), close window (Ctrl+Shift+W
), quit application (Ctrl+Shift+Q
) and private browsing (Ctrl+Shift+P
). It might be useful to expand these options to more shortcuts, in case there are other shortcuts that web apps commonly use that conflict with built-in Firefox shortcuts.Additionally, it still needs to be considered which of the shortcuts will have this new option enabled by default, and which will remain reserved by default.
Another thing to consider is how to implement settings UI for this. Possibly the easiest option is to add another list, similar to the existing shortcuts list, that determines just if a specific shortcut is reserved. However, this may be quite long if more shortcuts are added and possibly confusing to users (since the reserved part would not have an effect if the shortcut is completely disabled). A better option is to add some kind of three-way switch for each shortcut that determines if the shortcut is disabled, unreserved or reserved.
The text was updated successfully, but these errors were encountered: