You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#2241 adjusted dragElement to take care of click events as well. This has a number of benefits: it simplifies all the click vs (drag)done logic, and ensures that you do exactly one of those - a mousedown/up must be either a click or a drag. It also allows us to capture right clicks. Some TODOs came up in that PR:
Any trace type that uses selection.on('click', clickHandler) would benefit from being converted to dragElement, for the above mentioned reasons. This includes at least geo, mapbox, parcoords, pie, sankey, table. geo has a couple of additional issue: right-click starts a pan/select, which then you have to click again to get out of; it also needs to have hover effects removed when you start selecting or panning.
Annotations have a plotly_annotationclick event that should also be extended to support right-click.
Possibly create a config parameter to manage right-click behavior. Right now the hacky behavior that some users depend on is that if you attach a contextmenu handler to gd, and call preventDefault() in it, this prevents the native context menu from appearing, and then a right click (for those traces using dragElement anyway) get a plotly_click event and the dev can look at button(s), ctrlKey, etc to determine what kind of a click it was. But we don't want this to always, as mostly devs won't be thinking about what kind of click they're getting, and folks may want to keep the native context menu accessible. A config option seems like a clean way to expose this.
Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson
Activity
alexcjohnson commentedon Jan 10, 2018
#2241 adjusted
dragElementto take care ofclickevents as well. This has a number of benefits: it simplifies all theclickvs (drag)donelogic, and ensures that you do exactly one of those - a mousedown/up must be either a click or a drag. It also allows us to capture right clicks. Some TODOs came up in that PR:selection.on('click', clickHandler)would benefit from being converted todragElement, for the above mentioned reasons. This includes at leastgeo,mapbox,parcoords,pie,sankey,table.geohas a couple of additional issue: right-click starts a pan/select, which then you have to click again to get out of; it also needs to have hover effects removed when you start selecting or panning.plotly_annotationclickevent that should also be extended to support right-click.contextmenuhandler togd, and callpreventDefault()in it, this prevents the native context menu from appearing, and then a right click (for those traces usingdragElementanyway) get aplotly_clickevent and the dev can look atbutton(s),ctrlKey, etc to determine what kind of a click it was. But we don't want this to always, as mostly devs won't be thinking about what kind of click they're getting, and folks may want to keep the native context menu accessible. A config option seems like a clean way to expose this.gvwilson commentedon Jun 10, 2024
Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson