Add universal context menus in JupyterLab

[pjbull]

Current Summary

• We plan on adding a universal context menu to JuptyerLab that will allow plugins to declare context menu items that are scoped by CSS selectors similar to our keyboard shortcut system.
• When a user context menu clicks on any DOM element, JupyterLab will automatically build a context menu for all actions that are relevant.
• If the user presses shift when while opening a context menu, we will allow the browser default context menu to open and not show our own.
• Currently we are blocked while we wait for the context menu stuff to be implemented in phosphor (Universal context menus phosphorjs/phosphor#139).

Original Comment

Steps

1. Open a notebook in jupyter lab (repo'd on jupyterlab 0.1.2, notebook 4.2.1)
2. Produce an image, e.g:

%matplotlib inline
import pandas as pd

d = pd.DataFrame({'a': np.random.randint(0, 10, 100),
                  'b': np.random.rand(100)})

d.plot.scatter(x='a', y='b')

1. Right-click on image.

Result

No ability to copy image to clipboard:

[blink1073]

Thanks for the report, @pjbull. It looks like we need to check for the HTML element that is clicked and potentially add other options.

[blink1073]

It could also be that clicking on an <img> tag should just bring up the default browser menu.

[pjbull]

Maybe this should actually be widened to handle context menus in the notebook generally. For example, you don't get copy-paste options when right-clicking text in input cells either.

Also, it may be nice to have Insert Cell Above/Below and Delete Cell in the context menu, but that's beyond parity.

[jasongrout]

I think that we should sparingly use context menus by default. Maybe have context menus only on the prompt number areas? I'm not sure we need them on documents at all if we have the same options in the top-level menu bar.

[blink1073]

For comparison: Cloud9 has a context menu in the file browser area, but uses the browser default in the document area.

[blink1073]

#585 removes the context menus from documents, but we should leave this open for discussion.

[ellisonbg]

@sccolbert @blink1073 @rnetro

I want to revisit the question of context menus.

First question:

Is it possible for us to trigger the browser context menu if a certain modifier is pressed with the contextmenu event?

Basically I am wondering if we can start to offer context menus where they make sense, while still offering an escape hatch for users to access the browser context menu.

Second question:

If that is possible, what is the best way to start implementing context menus. Should widgets/plugins do this on their own? Should we offer a centralize approach for this?

[blink1073]

It may be feasible to use simulate-event to create a targeted contextmenu event, but I'm not sure if all browsers would react properly to a synthetic context menu event.
IMO a context menu should solely belong to the item it is being triggered on, and the plugin providing that item should decide whether to add extension points.

[jasongrout]

IMO a context menu should solely belong to the item it is being triggered on, and the plugin providing that item should decide whether to add extension points.

and the default should be to present the browser context menu?

[blink1073]

I understood Brian's position to be that our menu should be the default, with the system menu being available using a modifier.

[Carreau]

Html has a contextmenu element, [mdn], which is implemented only by Firefox AFAICT ; and append things to the browser context menu. Can we investigate if Chrome/IE are planning to implement by default that as well ? I seem relatively straightforward to use, if it's going to become mainstream

[sccolbert]

There doesn't seem to be any traction by other browsers to implement extensible context menus last time I checked.

The original post also brings up another point about copying images/arbitrary stuff to the clipboard. IIRC there are some security policies in place which make this extremely difficult/impossible to do. Something about not being able to copy to clipboard unless it's on the path of a "trusted" event. Using our own custom context menus means we're never on a trusted event path. So it may be a bit of a Catch-22. I'll need to look into it again.

[ellisonbg]

Is it viable to bring up own own or the system one based on a keyboard modifier? That gives us the best of both worlds...(or worst)

[sccolbert]

Yeah, if we want the system context menu, we just do nothing in our contextmenu handler. If we want the custom one, we cancel the original event and open our custom menu.

[ellisonbg]

This is implemented in master, closing.