Addresses issue pointed by out @nathansobo in #15277 where keybindings
for unfocusable nodes were being surfaced as accelerator indicators in
context menus.
When you right click in the DOM, your focus goes to the first focusable
ancestor of your click target. This change uses the ancestor that you
are actually focused on when looking for avaliable key bindings rather
than using the event target directly. This ensures that any surfaced key
bindings are actually reachable.
Electron allows us to pass an "accelerator" property for each menu item, which
is renders to the right of the menu item. We were already adding these for the
application level menus.
This pull request adds the accelerator property to regular context menu items,
which should make it easier for people to discover/recall key mappings for
actions which they usually take via a context menu.
Searching the code base and the GitHub repository shows no usage or
documentation for these two methods.
From what I can surmise, the call to `convertLegacyItemsBySelector` was removed
in cc4ee92699
by @thomasjo but these methods just weren't cleaned up.
This reverts commit 9917ed39aa.
Sorry, apparently I don't know how to use Git anymore.
I'm just trying to put this up for review and it went straight
to master instead.
This preserves the original behavior, in which passing undefined to
atom.contextMenu.add was a no-op that returned a no-op disposable.
Signed-off-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Rather than using order to specify item precedence, we now construct
a set of menu items for each element traversing upward from the target.
When merging items for a given element, we pass the specificity to the
merge function, which uses it to decide whether or not to clobber
existing items. When assembling the overall menu, we don’t ever clobber
to ensure that items added for elements closer to the target always win
over items matching further up the tree.