event.target of panstart is not the actual target where pan started

[LeJared]

Example
http://codepen.io/anon/pen/doZKmr

When dragging one of the red squares the event.target of panstart ist displayed in the gray area below. Note, that hammer is not bound to the red squares itself but to the outer div#stage!

Expected behavior
When dragging those red squares with the mouse I expect the event.target of panstart to be the red square where the user actually clicked (where the mousedown event had occurred).

Actual behavior
event.target is the element where the mouse pointer is, after the it has moved at least pan.options.threshold pixels away from the mousedown position. On slow systems/browsers this also may be a much greater distance since the mouse may have moved much further away until the next mousemove-event is issued from the browser.

Workaround
My current workaround is, that I use the current pointer position of the mouse at panstart, subtract event.deltaX / event.deltaY to compute the actual panstart-position and get the element from that point with document.elementFromPoint(x, y)

[runspired]

You can get the original target from from the e.srcEvent.target. You don't need the document.elementFromPoint hack.

@arschmitz I don't believe this is a bug, it was likely the original intention that target referred to the element being listened on (to differentiate manager instances), given that is where the corresponding gesture DOM event is originating.

I do think when improving the events created we ought to consider mirroring the source event's target.

Closing as I don't believe this is a bug, but I do think #808's eventing upgrade should this take into consideration.

[LeJared]

No, you can't use e.srcEvent.target. It does not change anything, because it always has the same value as e.target. See updated example: http://codepen.io/anon/pen/XbzxwP

The problem ist not, that e.target is set to the wrong element. It is set at the wrong time. It is supposed to be the element where mousedown had occurred. Instead it is set to the element, where mousemove was fired when pan.options.threshold was reached and thus a pan was recognized and panstart fired. You can see this, when you try dragging one of the small red squares. On the big red square you'll see, that e.target is set correctly when you don't move the mouse outside of the square until threshold has reached and panstart was fired.

So please reopen this bug.

BTW: e.target never was the element being listened to. It always was the actual element where the event was fired within the element you are listen to

[runspired]

@arschmitz When I tested this I missed that it was the mousemove not the mousedown, it definitely seems to me that the src event should be set to mousedown.

[runspired]

Related:

• Suggest change event flow #818
• pinchin/pinchout fire extraneous pinch events #824

We need to check if this is fixed by: 92f2d76

[runspired]

Not fixed yet: http://codepen.io/runspired/pen/meaPgM