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.
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.
Previously I used CSS specificity to order the most specific / recently
added menu items for a given element *first* when building up the
context menu. When a duplicate label was found for a given menu I would
refrain from inserting it. Now instead I order things the opposite way.
The most specific / recently added items come later and items with the
same label are clobbered by later items.
