Context Menu for VSCode integration

[tortmayr]

Currently it's not possible to contribute to the context menu of a custom editor. In fact, the context menu for webviews is completely disabled. As a workaround the GLSP Diagram Menu has been contributed to the "editor menu" in https://github.com/eclipse-glsp/glsp-vscode-integration/pull/15.

There is an open issue for this https://github.com/microsoft/vscode/issues/54285. However, this issue is open since 2018 and has not been tackled yet. It's unlikley that it will be resolved soon. If we really need a context menu we'd have to implement a custom solution.

@lforst already has provided MVP for a context menu implementation that could be reused here: https://github.com/lforst/glsp-vscode-integration/tree/lforst/context-menu

[tortmayr]

Generic context menu support in webviews for VS Code is provided with this PR: https://github.com/microsoft/vscode/pull/154524 We should check wether this also works with custom editors once it's available as proposed API.

[tortmayr]

I have played around with the webview/context menu contribution point that was added in VS Code 1.72 to see whether this could be used to implement this feature. In theory this works but there are certain server limitations:

• No support for dynamic/server-side provided context menus. The VS Code extension API only allows declarative contributions to the webview context menu via package.json. This means we cannot register context menu items that have been received via ContextMenuItemProvider from the glsp server.
• Limited use of webview/context when enablement condition: Typically we need diagram specific information to determine whether an menu item should be enabled (IsSelected, hasValidationMarkers, is deletable etc..). This diagram specific information lives in the webview and needs to be send to the host extension and translated to context keys so that the when condition can be properly evaluated. This results in an inherit timing issue, as the webview would have to listen to the contextMenu event and send the context info to the host extension. This happens async so there is no way to guarantee that the info is received and evaluated before the context menu is shown
• Some issues regarding focus loss/restoring that I did not investigate further so far.

In general, it would be better to use a custom context menu implementation that lives in the webview. This would give access to all diagram related information and also enables dynamic menu items provided by the server. Regarding styling it could be aligned with the default vscode context menu (same size, css keys etc.) so that it integrates fluently with the rest of the IDE. (Optionally we could also provide a custom contribution point that allows declarative contributons via package.json) While this is significantly more effort than just integrating the webview/context endpoint it is probably the referred solution.

For now let's move this into the back log until we have a concrete use case and/or sponsor for this feature.