New issue
Advanced search Search tips

Issue 721485 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

offsetX/offsetY are not set correctly on coalesced events

Project Member Reported by tbuck...@chromium.org, May 11 2017

Issue description

Chrome Version: 58.0.3029.111 (Official Build) beta (64-bit)
OS: Chrome

What steps will reproduce the problem?
(1) Go to http://jsbin.com/bigumumogo/3/edit?console,output
(2) Try drawing with/without coalesced events

What is the expected result?
Same line in either case (with coalesced points should just have more points)

What happens instead?
Coalesced points have very different offsetX/offsetY, causing line to be much lower.

Repro'd on Mac as well
 
Labels: -Pri-3 Pri-1
Summary: offsetX/offsetY are not set correctly on coalesced events (was: Offset )
Labels: -Pri-1 Pri-3
Owner: nzolghadr@chromium.org
Don't use offsetX/offsetY.

Since coalesced points aren't hit tested and don't have a target.  Fields relative to the target location return the same offset as the clientX/clientY.

We might want to call this out explicitly in the coalesced event spec I guess.
 But if you read: https://drafts.csswg.org/cssom-view/#dom-mouseevent-offsetx then you will likely see that since coalesced events aren't actually dispatched then offsetX ends up being clientX.
I believe we didn't assign these events a target because we didn't want to run through the list at every step of the event dispatch stage.

ie. A bubbling event to a parent will return a different offsetX at each target as it is dispatched to in the event path.

But I agree this will cause a bunch of interop issues like this.

Comment 5 by wfurr@google.com, May 12 2017

Without offsetX/Y on the coalesced events, I have to hit the DOM to calculate the offsets which is a potentially big performance hit.

The parent event has a target set; I don't see why the children wouldn't have the same target / offset as the parent event.

Comment 6 by rbyers@chromium.org, May 12 2017

> I believe we didn't assign these events a target because we didn't want to run through the list at every step of the event dispatch stage.
> ie. A bubbling event to a parent will return a different offsetX at each target as it is dispatched to in the event path.

I don't think that's true.  'currentTarget' changes during bubbling, but 'target' doesn't except for the special case of ShadowDOM retargetting.

> But I agree this will cause a bunch of interop issues like this.

There shouldn't be "interop" issues in that all browsers should behave this way since it's required by the spec for offsetX (assuming that it's actually pageX we return as required by the spec, not clientX).  Perhaps we should add a web-platform-test to validate the behavior though?

But I agree it could cause confusion, especially since we want people to be able to convert/share existing code to use coalesced events.  I filed a spec issue to discuss the design further: https://github.com/w3c/pointerevents/issues/209
Status: Fixed (was: Assigned)

Sign in to add a comment