Skip to content

Tools (e.g. select) should not execute on contextmenu #248

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

Closed
joshua-gould opened this issue Feb 10, 2016 · 7 comments
Closed

Tools (e.g. select) should not execute on contextmenu #248

joshua-gould opened this issue Feb 10, 2016 · 7 comments
Labels
community community contribution

Comments

@joshua-gould
Copy link
Contributor

All tools (e.g. select) have their click handler invoked when right-clicking.

@etpinard
Copy link
Contributor

Can I ask you why?

@joshua-gould
Copy link
Contributor Author

I'd like to create a custom popup menu on right-click (contextmenu event)

@etpinard etpinard added the community community contribution label Feb 15, 2016
@etpinard
Copy link
Contributor

@joshua-gould I labelled this issue with the community tag meaning that the no plotly.js team member will dedicate time to it, but PR are welcomed to address this issue.

@AlexVvx
Copy link

AlexVvx commented Oct 10, 2017

Hi, guys. I pulled pr about context menu. When {rightClick: false} is in options, then 'contextmenu' event will be fired on element and default browser menu prevented. Please take a look at https://github.com/AlexVvx/plotly.js/pull/1/files

@alexcjohnson
Copy link
Collaborator

@AlexVvx interesting, thanks for the PR! I wonder though if there isn't a simpler solution - we probably don't really want to trigger dragelement if you right click no matter what. Can we just look at e.button and/or e.buttons and bail out of onStart if it's not a left-click? If we do that, your own contextmenu event handler should pick up the event, right?

I haven't looked at browser support of the button attributes - note that we target IE9+ in addition to current versions of Chrome, FF, Edge, and Safari.

Touch interactions are an interesting case, you generally get contextmenu on a long press there, right? But might this already work correctly, since in touch environments we don't create a coverSlip at all (which I'm assuming is what interferes with the expected contextMenu on desktop)?

@AlexVvx
Copy link

AlexVvx commented Oct 12, 2017

Sounds good, applied changes in new pr

@alexcjohnson
Copy link
Collaborator

closed by @AlexVvx in #2087

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community community contribution
Projects
None yet
Development

No branches or pull requests

4 participants