Open Bug 1333781 Opened 7 years ago Updated 1 year ago

Allow existing (built-in) menu shortcuts to be reassigned as custom shortcuts via System Preferences

Categories

(Core :: Widget: Cocoa, defect, P3)

Product:
Core
Component:
Widget: Cocoa
Platform:
All
macOS
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox54 --- wontfix

People

(Reporter: spohl, Unassigned)

References

Details

(Whiteboard: [tpi:+])

Attachments

(2 files)

debug patch for com.apple.userkeyequivalentsdidchange notification
(deleted), patch
Details | Diff | Splinter Review
Screenshot
(deleted), image/png
Details 
+++ This bug was initially created as a clone of Bug #429824 +++

Bug 429824 added handling for custom shortcuts by the native menu system if the shortcut was not an existing, built-in shortcut. We should expand this to allow for reassignment of existing shortcuts. There seem to be two possible approaches:

1. Use the existing mechanics to set the built-in shortcuts, but remove the internal handling of the shortcuts via XBL prototype handlers[1] and let the native menu system handle them instead. This is scary because of the code we currently use to walk and execute our handlers[2]. It is unknown if this special handling is necessary and whether we can achieve the same via the native menu system.
2. Revert the change in bug 429824 and instead keep our XUL representation of keyboard shortcuts in sync with any custom shortcuts set via System Preferences. We would continue to use XBL prototype handlers to execute commands associated with a menu item. This would require that we check if the system has a custom shortcut set for every menu item that we create during startup. If yes, we need to translate and update the shortcuts in XUL. We would also need to listen for com.apple.userkeyequivalentsdidchange notifications from the system. This notification is sent if the user sets a custom shortcut for a menu item while Firefox is running. It may be easiest to set the menu to be rebuilt at this point. We don't have to listen for this notification if we go with approach 1 above as the native menu system will take care of this for us.

Also note that at present, existing and custom shortcuts in the application menu are already handled by the native menu system. We should get the behavior of the application menu in sync with the main menu, either as part of this bug or a separate bug.

[1] https://dxr.mozilla.org/mozilla-central/rev/6dccae211ae5fec6a1c1244b878ce0b93860154f/widget/cocoa/nsChildView.mm#5474
[2] https://dxr.mozilla.org/mozilla-central/rev/6dccae211ae5fec6a1c1244b878ce0b93860154f/dom/xbl/nsXBLWindowKeyHandler.cpp#637
This is a debug patch that I put together for solution 2. It was used to observe the com.apple.userkeyequivalentsdidchange notification and to set the menu items to be rebuilt. It does not attempt to update our XUL representation of shortcuts yet. There are a number of printf statements left in the patch. I'm uploading this in case it helps jumpstart an actual patch.

Any progress with this? It's truly annoying on macOS. Even Excel, Word, Powerpoint now handle this correctly

(In reply to Stephen A Pohl [:spohl] from comment #0)

  1. Use the existing mechanics to set the built-in shortcuts, but remove the
    internal handling of the shortcuts via XBL prototype handlers[1] and let the
    native menu system handle them instead. This is scary because of the code we
    currently use to walk and execute our handlers[2]. It is unknown if this
    special handling is necessary and whether we can achieve the same via the
    native menu system.

I'd like to try to fix this bug. Could you point me to the resources on what "XBL prototype handlers" are?

[Tracking Requested - why for this release]:

status-firefox74: --- → affected

(In reply to hongsy2006 from comment #16)

(In reply to Stephen A Pohl [:spohl] from comment #0)

  1. Use the existing mechanics to set the built-in shortcuts, but remove the
    internal handling of the shortcuts via XBL prototype handlers[1] and let the
    native menu system handle them instead. This is scary because of the code we
    currently use to walk and execute our handlers[2]. It is unknown if this
    special handling is necessary and whether we can achieve the same via the
    native menu system.

I'd like to try to fix this bug. Could you point me to the resources on what "XBL prototype handlers" are?

This is referenced in comment 0, in particular link [2]. You should expect to have to do a lot of debugging in the actual code to get a better understanding of the mechanisms here. Other resources will be limited at best and I wouldn't know of any off-hand.

Please do not change tracking flags.

status-firefox74: affected → ---

(In reply to hongsy2006 from comment #16)

I'd like to try to fix this bug. Could you point me to the resources on what "XBL prototype handlers" are?

This has been driving me crazy lately. Did you make any headway on this that can be shared?

Team, any news on this bug? This one has been raised 5 years ago, any option to have it fixed soon?
Thanks

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 13 duplicates and 11 votes.
:spohl, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(spohl.mozilla.bugs)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(spohl.mozilla.bugs)

This bug is still relevant and the severity of S3 is correct.

Thunderbird has quite a lot of default shortcuts, and some of them are outright dangerous since they require no modifier keys: it happens regularly that I think I am typing in the 'filter' field, but Thunderbird actually interprets my keystrokes as shortcuts. Then I spend the next 10min trying to figure out what my 10 keystrokes did and un-doing that. (In particular un-doing an accidental "ignore thread" is really hard.)

I think the severity should be raised, at least to provide a way to disable/remap the potentially destructive modifier-free shortcuts (J, K -- maybe there are others but these are the most painful).

As a left-hander, it is extremely difficult for me to use Firefox when I need to cut, copy or paste something. The standard keyboard shortcuts Cmd + X, Cmd + C and Cmd + V do not suit me and are very inconvenient, which is why I assigned these functions to the F13, F14 and F15 keys on the Apple Magic Keyboard with Touch ID and Numeric Keypad. And these keys work great in Safari, Chrome, and the entire system, including Spotlight. But they don't work in Firefox, and that's terribly annoying! 😠

Attached image Screenshot (deleted) —

Encountering the same problem.

I remapped the copy/paste/cut/undo/redo.

only undo works with both shortcuts command+z / ctrl+z , which is curios.

Name 	Firefox
Version 	108.0.1
Build ID 	20221215175817
Update Channel 	release
User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:108.0) Gecko/20100101 Firefox/108.0
OS 	Darwin 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000

(In reply to René W. from comment #35)

I remapped the copy/paste/cut/undo/redo.

only undo works with both shortcuts command+z / ctrl+z , which is curios.

Name 	Firefox
Version 	108.0.1
Build ID 	20221215175817
Update Channel 	release
User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:108.0) Gecko/20100101 Firefox/108.0
OS 	Darwin 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000

Will this change appear in the next version of Firefox? Or do you need permission from the developers?

My understanding is that S3 means "Blocks non-critical functionality and a work around exists".

From what I can see, there is no workaround available here. If a workaround does exist, I'd appreciate it if someone would let me know.

(In reply to me from comment #37)

From what I can see, there is no workaround available here. If a workaround does exist, I'd appreciate it if someone would let me know.

All menu items are accessible via the menu bar, clicking on the respective menu and selecting the desired menu item.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: