Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for disabling JupyterLab's context menu #7877

Merged
merged 14 commits into from Mar 18, 2020

Conversation

saulshanabrook
Copy link
Member

@saulshanabrook saulshanabrook commented Feb 12, 2020

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:

Screen Shot 2020-02-12 at 4 38 32 PM

Screen Shot 2020-02-12 at 4 38 50 PM

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.

Fixes jupyterlab#7670 by disabling JuptyrLab's context menu on all elements which
are children of elements with the `data-native-context-menu` property.
@jupyterlab-dev-mode
Copy link

@jupyterlab-dev-mode jupyterlab-dev-mode bot commented Feb 12, 2020

Thanks for making a pull request to JupyterLab!

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

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Feb 12, 2020

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
Copy link
Member Author

@saulshanabrook saulshanabrook commented Feb 12, 2020

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.

This now matches lumino keyboard shortcuts disable data attribute
@saulshanabrook
Copy link
Member Author

@saulshanabrook saulshanabrook commented Feb 12, 2020

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

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Feb 12, 2020

data-jp-suppress-context-menu

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

Co-Authored-By: Jason Grout <jasongrout@users.noreply.github.com>
Co-Authored-By: Jason Grout <jasongrout@users.noreply.github.com>
KrishnaKumarHariprasannan pushed a commit to KrishnaKumarHariprasannan/jupyterlab-event-order-demo that referenced this issue Feb 13, 2020
@blink1073
Copy link
Member

@blink1073 blink1073 commented Feb 15, 2020

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
Copy link
Member Author

@saulshanabrook saulshanabrook commented Feb 15, 2020

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

@blink1073
Copy link
Member

@blink1073 blink1073 commented Feb 17, 2020

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
Copy link
Contributor

@jasongrout jasongrout commented Feb 25, 2020

test

@saulshanabrook
Copy link
Member Author

@saulshanabrook saulshanabrook commented Feb 26, 2020

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

Screen Shot 2020-02-26 at 12 29 16 PM

@saulshanabrook
Copy link
Member Author

@saulshanabrook saulshanabrook commented Mar 17, 2020

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?

@vidartf vidartf merged commit d87de68 into jupyterlab:master Mar 18, 2020
19 of 22 checks passed
@saulshanabrook saulshanabrook deleted the right-click-option branch Mar 19, 2020
@saulshanabrook
Copy link
Member Author

@saulshanabrook saulshanabrook commented Mar 19, 2020

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
Copy link
Contributor

@jasongrout jasongrout commented Mar 19, 2020

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
Copy link
Member Author

@saulshanabrook saulshanabrook commented Mar 19, 2020

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
Copy link
Contributor

@jasongrout jasongrout commented Mar 19, 2020

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.

@saulshanabrook saulshanabrook modified the milestones: 2.0.2, 2.1 Mar 30, 2020
@lock lock bot added the status:resolved-locked label May 5, 2020
@lock lock bot locked as resolved and limited conversation to collaborators May 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation enhancement pkg:application status:resolved-locked tag:Design and UX tag:Extensions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants