Add support for disabling JupyterLab's context menu

[saulshanabrook]

Fixes #7670 by disabling JuptyrLab's context menu on all elements which
are children of elements with the data-jp-suppress-context-menu data-native-context-menu property.

I tested this out by modifying the JSON renderer to disable the context menu:

References

#7670

Code changes

Checks if the data-native-context-menu property is on a node, when you right click on it,
or any of its parents. If so, disables JupyterLab's default context menu and lets anyone else handle the vent as they would like.

User-facing changes

None.

Backwards-incompatible changes

Any elements that already happen have the data-native-context-menu attribute will not show the JupyterLab context menu when you click on them.

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[jasongrout]

data-native-context-menu

How does the name here compare with the name for disabling keyboard shortcuts? Should we namespace it to JupyterLab, since data attributes are a global namespace?

[saulshanabrook]

Great questions.

@afshin can you point me to the keyboard shortcut code? I found jupyterlab/jupyterlab-shortcutui#50 but not sure where the magic data- attribute lives in Lumino.

EDIT: Found it data-lm-suppress-shortcuts, it was using hasAttribute instead of dataset so didn't see it at first.

[saulshanabrook]

@jasongrout I changed to data-jp-suppress-context-menu to match convention of data-lm-suppress-shortcuts

[jasongrout]

data-jp-suppress-context-menu

Thanks, that's more descriptive and conservative to me.

[blink1073]

I think you need to use jsx as the lexer:

/home/vsts/work/1/s/docs/source/developer/extension_points.rst:134: WARNING: Could not lex literal_block as "typescript". Highlighting skipped.

[saulshanabrook]

@blink1073 Thank you for catching this! Maybe I should actually start paying attention to when our docs fail to build :D

[blink1073]

It looks like the lexer still can't handle the block, perhaps because of the data- attribute. We might have to format as generic code.

[jasongrout]

test

[saulshanabrook]

Seems like all tests passed besides windows JS, but weren't updated cause of github outage:

[saulshanabrook]

The docs are failing, but I believe just from a response from the Github API when checking the links:

https://github.com/nteract/vdom - 429 Client Error: too many requests for url: https://github.com/nteract/vdom

Otherwise, this is good to go. Any blockers on merging this?

[saulshanabrook]

Thanks @vidartf for merging. Since this is in master, does it mean it will be released in a 2.0.1 instead of having to wait for 3.0.0?

[jasongrout]

This isn't really a bugfix. You're not the first person to ask about having something released before 3.0, though. Perhaps the community would really rather have a 2.1 at some point before June, rather than another week of work on 3.0?

[saulshanabrook]

Yeah. I remember having a conversation about this before 2.0 went out and the sentiment was "Lets not block on this for 2.0, we will have a minor release very shortly after and it can go in that since it isn't breaking." That is what I communicated to others as well.

I can commit to being the "release coordinator" (or whatever term we wanna call it) for 2.1.0, making sure all the necessary things are done, if that would be helpful. I don't wanna just push more work on you!

[jasongrout]

Thanks. Our thoughts in the 3.0 planning meeting was that 3.0 is not a really long time away, so let's not stop work on 3.0 to ship 2.1. But if we can scale out the release managers, that's another way to ease the burden.

Let's take this up over on #8038 to decide a good time for a 2.1 release.