Skip to content
New issue

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

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

Already on GitHub? # to your account

Handle orphaned gestures. #18

Closed
mblandfo opened this issue Sep 24, 2016 · 4 comments
Closed

Handle orphaned gestures. #18

mblandfo opened this issue Sep 24, 2016 · 4 comments

Comments

@mblandfo
Copy link

Reproduction: https://jsfiddle.net/njjd40vj/1/ (modified from http://bl.ocks.org/mbostock/b0d0aa4df3b5c3c0fa37d4b3f2127740 just to log start/end events)

IE 11:

  1. open console, brush a bit, notice "start" and "end" brush events get logged
  2. mouse down, mouse off browser,
  3. mouse up. start is logged, but end is not
  4. mouse back on browser, try to keep brushing. start and end events no longer get logged.

Chrome:

Change 3) to be
3) mouse over another window. right click (left button is still down). end is not logged and start/end events no longer fire

@mblandfo
Copy link
Author

mblandfo commented Sep 24, 2016

This was on Windows 7. It does not appear to reproduce on Mac Chrome.

@mbostock
Copy link
Member

Hmm. Not sure if I’m going to be able to do much with this. I can use VirtualPC to test Windows, but I don’t have a lot of resources to debug platform-specific issues and often rely on contributors for fixes.

If the mouseup is not received by the window, then the brush will still consider the gesture active. Per brush.js, only the start of the first active gesture will trigger a start event, and only the end of the last active gesture will trigger an end event. So it’s totally plausible that if the browser fails to dispatch the mouseup event, that you never see subsequent start and end events (on that specific element), because it still considers the earlier gesture to be active.

It sounds like the browser isn’t dispatching the mouseup event because it’s outside the window. Unfortunately this behavior isn’t standardized (see d3/d3-drag#9), so we’re all waiting for element.setPointerCapture to capture events reliably. An alternative might be to deem certain input events as terminating any active gestures and starting a new gesture: a mouseup event, or a touchstart event where event.changedTouches.length === event.touches.length. But that assumes that a mouse and touch can’t be active simultaneously, which isn’t true of all devices.

@mblandfo
Copy link
Author

Perhaps it could be an option passed in to make mousedown terminate a gesture and start a new one. Maybe default to this. Or - if there are no active touches and you get a mousedown, that should terminate and start anew.

I'm not familiar with all the use cases here so I'm just asking: on some devices you can touch and mouse, but why would you want to do them both at once to use the brush? Multiple touches with no mouse makes sense I think.

@mbostock mbostock changed the title brush start and end events can get broken Handle orphaned gestures. Sep 26, 2016
bhousel added a commit to openstreetmap/iD that referenced this issue Dec 6, 2016
(closes #2151), (see also d3/d3-zoom#60, d3/d3-brush#18)

Intercept `mousedown` and check if there is an orphaned zoom gesture.
This can happen if a previous `mousedown` occurred without a `mouseup`.
If we detect this, dispatch `mouseup` to complete the orphaned gesture,
so that d3-zoom won't stop propagation of new `mousedown` events.
@mbostock
Copy link
Member

mbostock commented Aug 2, 2019

An alternative might be to deem certain input events as terminating any active gestures and starting a new gesture: a mouseup event, or a touchstart event where event.changedTouches.length === event.touches.length.

I did this.

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

No branches or pull requests

2 participants