I don't see anything wrong with matrixTransform, however it seems that one of the getScreenCTM calls (et) returns unexpected/incorrect results (looks like box position is incorrect.) Calling getScreenCTM on the same element in Devtools after the test has run appears to give a more reasonable matrix though, so maybe something awry with the layout during load... A bisect might help there.

Regression range is 

https://chromium.googlesource.com/chromium/src/+log/c5b606c3188dac60dd3f8e29bafbb90d95089c3e..5ae55b8c8ed39e3a1019afba988b5df208f53420

of which this is probably it:

https://chromium.googlesource.com/chromium/src/+/2ad2a9bf7205ec77843cf27a7964fda92df386b2

Oh, this is the <use> local space "duality" rearing its ugly head (again)... *sigh*

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

commit 9acc325d119247a27d0a007d56fc6cc2fa23edc7
Author: fs <fs@opera.com>
Date: Tue May 02 16:05:32 2017

getScreenCTM on <use> should not include the additional translation

This is a partial revert of https://codereview.chromium.org/2711503002,
preserving the fix from that bug ( crbug.com/678167 ) while restoring the
LocalCoordinateSpaceTransform() infrastructure to compute the correct
CTM for <use> elements.

BUG= 716711 

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

[add] https://crrev.com/9acc325d119247a27d0a007d56fc6cc2fa23edc7/third_party/WebKit/LayoutTests/svg/dom/getscreenctm-use-with-additional-translation.html
[modify] https://crrev.com/9acc325d119247a27d0a007d56fc6cc2fa23edc7/third_party/WebKit/Source/core/svg/SVGElement.cpp
[modify] https://crrev.com/9acc325d119247a27d0a007d56fc6cc2fa23edc7/third_party/WebKit/Source/core/svg/SVGElement.h
[modify] https://crrev.com/9acc325d119247a27d0a007d56fc6cc2fa23edc7/third_party/WebKit/Source/core/svg/SVGGraphicsElement.cpp
[modify] https://crrev.com/9acc325d119247a27d0a007d56fc6cc2fa23edc7/third_party/WebKit/Source/core/svg/SVGGraphicsElement.h
[modify] https://crrev.com/9acc325d119247a27d0a007d56fc6cc2fa23edc7/third_party/WebKit/Source/core/svg/SVGPatternElement.cpp
[modify] https://crrev.com/9acc325d119247a27d0a007d56fc6cc2fa23edc7/third_party/WebKit/Source/core/svg/SVGPatternElement.h
[modify] https://crrev.com/9acc325d119247a27d0a007d56fc6cc2fa23edc7/third_party/WebKit/Source/core/svg/SVGSVGElement.cpp
[modify] https://crrev.com/9acc325d119247a27d0a007d56fc6cc2fa23edc7/third_party/WebKit/Source/core/svg/SVGSVGElement.h

Where can I learn more about the '<use> local space "duality"' issues?

Is there a similar "duality" issue regarding nested <svg>?  Chrome gives a getScreenCTM that reflects the inside of the nested <svg>... Firefox gives getScreenCTM that reflects the outside of the nested <svg>... for the placement of the SVG itself, and has rejected several tickets to change it, claiming their interpretation conforms to the standard.

The "duality" is an implementation thing (headache) that revolves around whether or not the 'x' and 'y' on a <use> should be included in the local space transform (or CTM.) So in particular case we had included it when we shouldn't have.

As for nested <svg> I guess that comes down to whether or not the 'viewBox' (and 'preserveAspectRatio' effects) should be included? In SVG 1.1 that wasn't particularly well-defined [1], but based on the SVG2 wording [2] I'd say it should. (I would probably have argued that the "current user units" in this case ought to have been with the 'viewBox' included, but it's also said about 'viewBox' that: "If specified, an additional transformation is applied to all descendants of the given element to achieve the specified effect.")
It'd be interesting to also check what Edge does in this case.

[1] https://www.w3.org/TR/SVG11/types.html#__svg__SVGLocatable__getScreenCTM
[2] https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsElement__getScreenCTM

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit 351c73cdc0a9a1e1391893f1b44f40e419950b9f
Author: Fredrik Söderquist <fs@opera.com>
Date: Wed May 03 07:55:39 2017

getScreenCTM on <use> should not include the additional translation

This is a partial revert of https://codereview.chromium.org/2711503002,
preserving the fix from that bug ( crbug.com/678167 ) while restoring the
LocalCoordinateSpaceTransform() infrastructure to compute the correct
CTM for <use> elements.

BUG= 716711 

Review-Url: https://codereview.chromium.org/2853223002
Cr-Commit-Position: refs/heads/master@{#468657}
(cherry picked from commit 9acc325d119247a27d0a007d56fc6cc2fa23edc7)

Review-Url: https://codereview.chromium.org/2857863003 .
Cr-Commit-Position: refs/branch-heads/3071@{#370}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[add] https://crrev.com/351c73cdc0a9a1e1391893f1b44f40e419950b9f/third_party/WebKit/LayoutTests/svg/dom/getscreenctm-use-with-additional-translation.html
[modify] https://crrev.com/351c73cdc0a9a1e1391893f1b44f40e419950b9f/third_party/WebKit/Source/core/svg/SVGElement.cpp
[modify] https://crrev.com/351c73cdc0a9a1e1391893f1b44f40e419950b9f/third_party/WebKit/Source/core/svg/SVGElement.h
[modify] https://crrev.com/351c73cdc0a9a1e1391893f1b44f40e419950b9f/third_party/WebKit/Source/core/svg/SVGGraphicsElement.cpp
[modify] https://crrev.com/351c73cdc0a9a1e1391893f1b44f40e419950b9f/third_party/WebKit/Source/core/svg/SVGGraphicsElement.h
[modify] https://crrev.com/351c73cdc0a9a1e1391893f1b44f40e419950b9f/third_party/WebKit/Source/core/svg/SVGPatternElement.cpp
[modify] https://crrev.com/351c73cdc0a9a1e1391893f1b44f40e419950b9f/third_party/WebKit/Source/core/svg/SVGPatternElement.h
[modify] https://crrev.com/351c73cdc0a9a1e1391893f1b44f40e419950b9f/third_party/WebKit/Source/core/svg/SVGSVGElement.cpp
[modify] https://crrev.com/351c73cdc0a9a1e1391893f1b44f40e419950b9f/third_party/WebKit/Source/core/svg/SVGSVGElement.h

Thanks for the explanations of duality and nested SVG. I've used "canned" SVG stuff in the past, but in getting into generating my own, I'm finding there are lots of edge cases or vaguely defined stuff in the 1.1 spec, and it doesn't help that the current implementations also include some of 2.0 (except they are nice features, I would applaud further implementation of 2.0) which in some cases, like you point out, either "clarifies" or "changes" the way one should interpret the 1.1 spec.

And thanks for the fix, I'll try it out once the build includes it, but your explanation certainly fits with the offset my test case was experiencing.

Verified this issue on Windows 10, Ubuntu 14.04 and Mac 10.12.4 with chrome #59.0.3071.47 with provided html file in comment #0

Observed that curve and line at bottom should tilt up to the right.

Hence adding TE-Verified labels.

Deleted: Issue 716711-M59-Good.png 68.8 KB

	Issue 716711-M59-Good.png 68.8 KB View Download

Deleted: Issue 716711-M58-Bad.png 65.1 KB

	Issue 716711-M58-Bad.png 65.1 KB View Download

I still have this issue in Chrome version 59.0.3071.115  in Mac OS 12.5
The getCTM and matrixTransform still exists?

#16, please file a new bug and we'll take a look at it (also note that getScreenCTM != getCTM.)

Sure, filed it here 

https://bugs.chromium.org/p/chromium/issues/detail?id=747389