Bisected to:

https://chromium.googlesource.com/chromium/src/+/a663c6ee1aef79f2de75c7620b72cea48630b9ca

So I can acknowledge that there was a change in behavior.

CSSOM View says (for 'offsetX'):

"...return the x-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..."

(https://drafts.csswg.org/cssom-view/#dom-mouseevent-offsetx)

And in the Firefox I tested in (Nightly), they seem to implement the above with "padding edge" interpreted as "stroke bounding box", while Blink essentially just uses the origin (so offsetX of the left edge of the left circle is 0 in FF, while it is 40000 in Blink.) I tested Edge too, and they match our "old" behavior, so this seems like a bit of a compat hotzone... (+rbyers)

The click event listener is on the div containing the SVG. If you click in bounding rectangle of the SVG but not on a circle you get an offset from the top left of the div. If you click on one of the circles you get a scaled version of that. Since the event is on the div, shouldn't the offset be in the div coordinate space? How is the scaled offset useful for the div event listener? 

When you click on the <circle> within the <svg> (and <div>), the <circle> will be the target of the event. offsetX/Y is defined to be relative to the "target node" (see quote above). When the event handler installed on the <div> fires, the <div> will be the "current target". Compare to this simple example:

https://jsfiddle.net/4Lyogkd9/

I would suggest that you look into using properties other than offsetX/Y for your use-case.

Thanks for the explanation. I changed the implementation to avoid offsetX/Y. For what it's worth, the app has been working for a couple of years without issue until this update. 

Rick; this looks like an interop issue where we changed to match the spec but caused a wave of incompatibility. How do you wish to proceed?

So this would have first changed in Chrome 51, right?  Seems like a bit of an edge case that likely hasn't gotten much notice.

I'm not an expert an interpreting the CSS spec in context of SVG.  Is there some official definition of what "padding edge" means when it comes to SVG elements?  +simonp in case he can shed some light on the intention, or whether the spec should be clarified.

Regardless of what any spec says, if Edge, Firefox and WebKit already matched our old behavior it seems to me like we should just change back to match them.  Worst case we can hack something into the MouseRelatedEvent::computeRelativePosition code specific to SVG for this.

fs@, WDYT?  Can you look at restoring the offsetX/Y behavior to counter-act the effect your mapAncestorToLocal change had?

Special-casing SVG elements to always return the offset to the outermost <svg> (i.e the enclosing CSS layout box) should hopefully not be too difficult.

(I'll note though that per my analysis in c#1, recent Gecko implements what the current CSSOM View spec say, so we probably want to try to get them to revert whatever change they made too...)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bb725f3a42fd8caa33c542e46fe4d9fc7a72678f

commit bb725f3a42fd8caa33c542e46fe4d9fc7a72678f
Author: fs <fs@opera.com>
Date: Thu Jul 07 19:47:58 2016

Use the outermost SVG as base when computing offsetX/Y for SVG elements

This reverts the behavior back to what it was prior to
https://codereview.chromium.org/1747223002. In short, the closest
ancestor CSS layout box is used for any SVG element. This will always
be the outermost SVG root (LayoutSVGRoot.)

BUG= 624996 

Review-Url: https://codereview.chromium.org/2124283002
Cr-Commit-Position: refs/heads/master@{#404217}

[add] https://crrev.com/bb725f3a42fd8caa33c542e46fe4d9fc7a72678f/third_party/WebKit/LayoutTests/fast/events/offsetX-offsetY-svg.html
[modify] https://crrev.com/bb725f3a42fd8caa33c542e46fe4d9fc7a72678f/third_party/WebKit/Source/core/events/MouseRelatedEvent.cpp

Your change meets the bar and is auto-approved for M53 (branch: 2785)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/162fbdaa3d5778e2f02a47c1595400d328df4b22

commit 162fbdaa3d5778e2f02a47c1595400d328df4b22
Author: Fredrik Söderquist <fs@opera.com>
Date: Mon Jul 18 09:33:26 2016

Use the outermost SVG as base when computing offsetX/Y for SVG elements

This reverts the behavior back to what it was prior to
https://codereview.chromium.org/1747223002. In short, the closest
ancestor CSS layout box is used for any SVG element. This will always
be the outermost SVG root (LayoutSVGRoot.)

BUG= 624996 

Review-Url: https://codereview.chromium.org/2124283002
Cr-Commit-Position: refs/heads/master@{#404217}
(cherry picked from commit bb725f3a42fd8caa33c542e46fe4d9fc7a72678f)

Review URL: https://codereview.chromium.org/2158793002 .

Cr-Commit-Position: refs/branch-heads/2785@{#179}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[add] https://crrev.com/162fbdaa3d5778e2f02a47c1595400d328df4b22/third_party/WebKit/LayoutTests/fast/events/offsetX-offsetY-svg.html
[modify] https://crrev.com/162fbdaa3d5778e2f02a47c1595400d328df4b22/third_party/WebKit/Source/core/events/MouseRelatedEvent.cpp

Tested the same on mac 10.11.5 chrome version 53.0.2785.21 - on clicking the blue circle observed the output as shown in the screenshot

Firefox behaviour : please find the screenshot

fs@opera.com, Could you please confirm if this is the expected behaviour

Deleted: Screen Shot 2016-07-19 at 2.40.59 PM.png 512 KB

	Screen Shot 2016-07-19 at 2.40.59 PM.png 512 KB View Download

Deleted: Firefox.png 68.3 KB

	Firefox.png 68.3 KB View Download

Yes, that looks like the expected behavior.

Thanks for the confirmation. Adding TE-Verified labels