[cssom-view] It is unclear when offsetX/Y are calculated

[smaug----]

https://drafts.csswg.org/cssom-view/#extensions-to-the-mouseevent-interface

The spec says
"return the x[y]-coordinate of the position where the event occurred relative to the origin of the padding edge of the target node, ignoring the transforms that apply to the element and its ancestors, and terminate these steps."

blink and webkit cache the value at the first access, Edge seems to cache it when event is created and Gecko calculates it always. My reading is that Gecko does it right, bz' reading is that Edge does it right, but then, blink/webkit model is the fastest.

[bzbarsky]

@zcorpan ping.

[bzbarsky]

Specifically, consider the behavior of these three testcases in the various browsers:

First:

<div style="position: relative" id="mydiv">
  Click on the "C" of the first "Click" in this line
</div>
<script>
document.getElementById("mydiv").onclick = function(e) {
  console.log(e.offsetX);
  document.querySelector("div").style.left = "200px";
  console.log(e.offsetX);
};
</script>

For this testcase, Gecko reports a number near 0, then a number near -200. Blink/WebKit report a number near 0 twice. Edge 14 matches WebKit/Blink. Live version at https://jsfiddle.net/7x5e701m/1/

Second:

<div style="position: relative" id="mydiv">Click on the "C" of the first "Click" in this line</div>
<script>
document.getElementById("mydiv").onclick = function(e) {
  document.querySelector("div").style.left = "200px";
  console.log(e.offsetX);
};
</script>

For this testcase, both Gecko and Blink/WebKit report a single number near -200. Edge reports a number near 0. Live version at https://jsfiddle.net/7x5e701m/2/

Third:

<div style="position: relative" id="mydiv">
  Click on the "C" of the first "Click" in this line
</div>
<script>
document.getElementById("mydiv").onclick = function(e) {
  var d = document.querySelector("div");
  d.style.left = "200px";
  console.log(d.offsetLeft)
  console.log(e.offsetX);
};
</script>

For this testcase, both Gecko and Blink/WebKit report a number near 200, then a number near -200. Edge reports a number near 200, then a number near 0. Live version at https://jsfiddle.net/7x5e701m/4/

[zcorpan]

So do we want the Blink/WebKit behavior?

[zcorpan]

cc @RByers

[smaug----]

webkit/blink behavior is the most surprising, but performance is better.
But I think I could live with that.

[RByers]

@dtapuska and @mustaqahmed are probably the right people on the blink input team to comment on this.

[FremyCompany]

I would note that these numbers should be easy to compute when you are doing your hit testing, which you need to do anyway to find the target. Except I recall Chrome does not do a lot of hit-testing for touch events so maybe in that case computing the number would be an extra effort?

[dtapuska]

I'd prefer that offsetX and offsetY were calculated only at the Event creation time and were not layout inducing properties fields. Being that this has been shipped by a few browsers already I don't see why we would want to do the more expensive approach making these fields layout inducing.

[bzbarsky]

I'd prefer that offsetX and offsetY were calculated only at the Event creation time

OK, that's the Edge behavior as far as I can tell, right?

I think the Edge behavior is strange

Given your previous sentence, I'm wondering what you think the Edge behavior is....

I don't see why we would want to do the more expensive approach making these fields layout inducing

Just so we're clear: they're layout inducing in Blink right now, the first time you call the getter. You seem to be arguing they never should be, which means the behavior of everyone except Edge should change. This does not seem a priori terrible to me, but I'm not sure how to reconcile that with your second sentence.

[dtapuska]

Let me clarify. I've removed my Edge comment that it is strange; it actually makes the most sense provided we can actually compute these values from the hit test.

Seems https://trac.webkit.org/changeset/82225 was the original change that introduced this behavior. And ultimately I think if (m_target == target) would have fixed the problem with the O(n^2) vs O(n) that the change was trying to address.

Chromium/WebKit reset the cached bool whenever the target changes for an event. Now a target is a readonly attribute so javascript can't set it although I believe the target changes when going into a shadow dom. So it could be possible that reading the cached value changes across the shadow DOM exhibits the "live" behavior FireFox has.

So granted it isn't as simple as determining it at hit testing time because the values depend on the target and the target might change across the shadow dom, right?

[bzbarsky]

Now a target is a readonly attribute so javascript can't set it

It can by explicitly doing dispatchEvent on it to some target, actually.

it isn't as simple as determining it at hit testing time because the values depend on the target and the target might change across the shadow dom, right

Ugh, yes, seems like it.