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

The default filter should return false if event.ctrlKey. #62

Closed
JHStoops opened this issue Jul 1, 2019 · 5 comments
Closed

The default filter should return false if event.ctrlKey. #62

JHStoops opened this issue Jul 1, 2019 · 5 comments

Comments

@JHStoops
Copy link

JHStoops commented Jul 1, 2019

Our page uses some fairly complex D3, but we've noticed an issue that can be consistently reproduced even in simple examples.

Steps to reproduce:

  1. (On a Mac) control + click on any draggable item or background, which opens a context menu;
  2. Click outside of the context menu to close it
  3. You're now in a dragging state, even though you released the click.
  4. click again to escape the drag state.

This doesn't happen when you replace the first step with a regular right-click; so we expect it might have something to do with the meta-key control being involved in the process that lets the key-down event trigger, but doesn't register the key-up event and thus thinks it's in drag state until a new click event is dispatched.

We made this codepen as an example. In its current form it uses microlibraries, but it gave the same results when importing the latest version of the full d3 library (v5)
https://codepen.io/anon/pen/rEdmRZ

And any example from https://github.com/d3/d3/wiki/Gallery that includes dragging, such as:
http://bl.ocks.org/robschmuecker/7880033
https://observablehq.com/@d3/versor-dragging
http://bl.ocks.org/shunpochang/66620bad0e6b201f261c

@mbostock
Copy link
Member

mbostock commented Aug 5, 2019

Currently our assumption is that the context menu is summoned via right-click, not control-click. The default filter is:

function filter() {
  return !d3.event.button;
}

We could change it to

function filter() {
  return !d3.event.ctrlKey && !d3.event.button;
}

but I don’t think we’d want to do this unless we knew that Control-Click brings up the context menu, since some users might want to use control key when dragging. I’m not sure how we’d be able to know the correct behavior since it is platform specific.

@JHStoops
Copy link
Author

JHStoops commented Aug 7, 2019

I think it's fair to assume that only a minority of users use control + click to open a context menu on Macs.

Thanks for looking into this. Keep up the amazing work!

@JHStoops JHStoops closed this as completed Aug 7, 2019
@mbostock
Copy link
Member

mbostock commented Aug 7, 2019

I think changing the default filter to ignore the gesture if d3.event.ctrlKey is true is a good idea, since it is the default on macOS, and people can always override this default if they want to allow dragging with Control.

@mbostock mbostock reopened this Aug 7, 2019
@mbostock mbostock changed the title Mac OS: forced drag event after control + click The default filter should return false if event.ctrlKey. Aug 7, 2019
@JHStoops
Copy link
Author

I just noticed you reopened the issue and implemented a fix. I tested it in our app, and it works like a charm. Thanks, good sir!

@curran
Copy link

curran commented May 31, 2023

I'm curious, if you remove the default filter and try to ctrl+drag on a Mac, does it work? I would guess that it does, because only ctrl+click (and not drag) would cause the context menu to appear.

I ask because I'm developing something with Ctrl+drag as a "thing" to trigger a certain behavior, and I'm not sure it would work on a Mac (I don't have access to a Mac). Fingers crossed it would work!

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

No branches or pull requests

3 participants