Technical issues related to context menus

[cpcallen]

This is a list of stuff I (@cpcallen) have observed about the implementation existing context menu system that might make it less-than-ideally suited for keyboard navigation, from a technical point of view.

• BlockSvg.prototype.showContextMenu needs a PointerEvent to know where to place the context menu.
• That PointerEvent is also later passed (as a required parameter) to the ContextMenuOption's callback when the menu item is chosen. (This was added in feat!: Add context menu options for workspace comments blockly#8035 to allow the workspace context menu entry for creating a workspace comment to know where to place the new comment).
• Faking the PointerEvent appears to be possible, but seems kludgy.
• Many of the blocks in the demo don't actually display a context menu. This is for a mix of reasons, but mainly because the choice of whether to have a context menu or not is ultimately up to the block (and thus to the developer who wrote the block definition). We can add any context menu options we like to the registry, but the block can decide for itself which to show—or whether to disabling the context menu for that block entirely.
• At the moment the only valid contexts for context menu items are blocks, workspace comments and the workspace itself. It seems like we may also need to support an action menu for connections (see 1, 2

I'm wondering whether we might be better to introduce a new kind of menu—a 'block nav menu'—that is less controlled by the block but which would include context menu items from the block.

(An alternative would be to change some of the existing context menu code to reduce the amount of control that developers have over the menu's contents—but obviously that would be a significant, breaking change.)

[rachel-fenichel]

Do you have a minimal patch that I can use to trigger the context menu with a fake pointer event so that I can play around with this?

[rachel-fenichel]

My thoughts:

• Call ContextMenu.show directly with a list of options generated in the keyboard navigation code, rather than calling block.showContextMenu. This avoids issues of the block blocking the context menu from appearing, and lets us directly add items.
• In core, add a keyboard navigation scope to the context menu registry. This won't interfere with the existing code.
• In keyboard navigation, update the context menu generation function to use ContextMenuRegistry.registry.getContextMenuOptions with the new scope type.

Still needs decision:

• Should keyboard nav + workspace and keyboard nav + block be separate scope types, with the context menu registry filtering the correct set of things, or should keyboard nav do the work to combine the various types of context menu items/scopes?