More context in context menu

[ian-r-rose]

There are a number of places in the UI where the phosphor context menu system is more limited than we would want, and it is causing trouble. The context menu is based upon CSS selectors, but if there is more than one node with the same (or intersecting) selectors, we currently have no way of distinguishing which one was clicked on.

This, for instance, is a blocker for moving the file browser over to the application context menu, since we need to know more about which file browser item was clicked upon, and how to get that information in the Open With submenu.

It is also a problem with the context menu items in the tabs of the main area (as noted in #4500). If the user right-clicks on a tab that is not the currently active one, it shows the right context menus, but the commands operate on the wrong widget. I am not sure the best way to fix this, but it would be nice to be able to get more information to the commands invoked in the context menu about which node was clicked.

[telamonian]

As a starting point for discussion on this issue, I've submitted a pull request (#4590) with a cleaned-up/more complete version of the focus fix I came up with when I was fiddling around with #4500.

The fix works by having the main app (ie the JupyterLab object) capture the most recent contextmenu event in a ._contextEvent property. The context menu constructor code can then inspect this property in order to get any information it needs about the menu-initiating event that isn't exposed by the current framework.

[telamonian]

I also added a lambda to the addCommands function in docmanager-extension/src/index.ts that exposes the widget specific to the document that was right-clicked on to initiate the contextmenu event:

// fetches the doc widget associated with the most recent contextmenu event
const contextMenuWidget = (): Widget => {
  let path = app.contextMenuTargetPath;
  if (!path) {
    // fall back to active doc widget if path cannot be obtained from event
    return app.shell.currentWidget;
  }

  return docManager.findWidget(path);
};

I then made the relevant subs in the code for the commands themselves (ie I replaced app.shell.currentWidget with contextMenuWidget() where the tab-specific document widget was needed).

In sum, this makes use of the new app._contextEvent property to fix the tab-focus issue brought up in #4500. rename... and the other commands now operate on the tab you actually right-click on, instead of just always operating on the active document (which is the behavior in the current master branch code).

[telamonian]

If you all (mostly @ian-r-rose, I suppose) consider the basic premise of the fix to be sound, I'm sure it can be expanded to cover the information needed by the file browser context menu in the Open With command and elsewhere.

On the other hand, I'm not at all familiar with TS design patterns/best practices. I figure there's a decent chance that my approach breaks desired encapsulation and/or exposes too much information to certain scopes. If so, what would be the appropriate way to expose the needed info?