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

NEW
Unassigned

Status

()

defect
P3
normal
2 years ago
3 hours ago

People

(Reporter: spohl, Unassigned)

Tracking

Trunk
All
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox54 affected)

Details

(Whiteboard: [tpi:+])

Attachments

(1 attachment)

Reporter

Description

2 years ago
+++ 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
Reporter

Comment 1

2 years ago
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.
Reporter

Updated

2 years ago
Duplicate of this bug: 1216675
Reporter

Updated

2 years ago
Duplicate of this bug: 1381952
Reporter

Updated

2 years ago
Duplicate of this bug: 1417216
Reporter

Updated

3 hours ago
Duplicate of this bug: 1552846
You need to log in before you can comment on or make changes to this bug.