There's a FIXME in SVGSVGElement::localCoordinateSpaceTransform:

// FIXME: This doesn't work correctly with CSS transforms.

which I think answers the "why". What's happening right now is that we're computing the location of the upper-left corner of the CSS layout box of the <svg> and then adding (prepending) that to the transform, "missing" the scale. Hopefully it's as easy as replacing localToAbsolute with localToAbsoluteTransform. (Probably flattening any 3d-components, at least at first, because there's some impedance mismatch here until we can return DOMMatrix from getScreenCTM.)

I'm including the spec link here for easy reference:
https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsElement__getScreenCTM

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

commit d0286404a0fdb943d9e69ea7af0ffc85e0435f87
Author: fs <fs@opera.com>
Date: Mon Feb 20 20:01:26 2017

Rewrite svg/zoom/page/zoom-get-screen-ctm.html to use testharness

In preparation for some future tweaks to this test.

BUG= 678167 

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

[delete] https://crrev.com/60698ac0ece866407aafdab0a71d18068ff111bc/third_party/WebKit/LayoutTests/svg/zoom/page/zoom-get-screen-ctm-expected.txt
[modify] https://crrev.com/d0286404a0fdb943d9e69ea7af0ffc85e0435f87/third_party/WebKit/LayoutTests/svg/zoom/page/zoom-get-screen-ctm.html

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

commit 2ad2a9bf7205ec77843cf27a7964fda92df386b2
Author: fs <fs@opera.com>
Date: Wed Feb 22 08:50:27 2017

Compute a more correct "screen scope" transform for SVGSVGElement

For getScreenCTM, only the position (translation) of the outermost svg
element was computed - any additional transform data was dropped.

Use LayoutObject::localToAbsoluteTransform to compute the full transform
rather than just the position of the layout box. Since using this method
works for any (attached) element, implement getScreenCTM without using
computeCTM, and get rid of the ScreenScope variant of the latter. This
also allows us to simplify SVGSVGElement::localCoordinateSpaceTransform
a bit, and drop the CTMScope argument from the
localCoordinateSpaceTransform declaration(s).

It's not clear from [1] how elements which are not in the rendering tree
(i.e has 'display: none' or similar) should be handled. With this
implementation we will return an identity matrix in those cases, which
doesn't seem unreasonable. (The option would be to return 'null', which
is how elements not in the document should be treated, but we don't have
that semantic implemented yet.)

[1] https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsElement__getScreenCTM

BUG= 678167 

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

[add] https://crrev.com/2ad2a9bf7205ec77843cf27a7964fda92df386b2/third_party/WebKit/LayoutTests/svg/dom/getScreenCTM-ancestor-transform.html
[modify] https://crrev.com/2ad2a9bf7205ec77843cf27a7964fda92df386b2/third_party/WebKit/LayoutTests/svg/zoom/page/zoom-get-screen-ctm.html
[modify] https://crrev.com/2ad2a9bf7205ec77843cf27a7964fda92df386b2/third_party/WebKit/Source/core/svg/SVGElement.cpp
[modify] https://crrev.com/2ad2a9bf7205ec77843cf27a7964fda92df386b2/third_party/WebKit/Source/core/svg/SVGElement.h
[modify] https://crrev.com/2ad2a9bf7205ec77843cf27a7964fda92df386b2/third_party/WebKit/Source/core/svg/SVGGraphicsElement.cpp
[modify] https://crrev.com/2ad2a9bf7205ec77843cf27a7964fda92df386b2/third_party/WebKit/Source/core/svg/SVGGraphicsElement.h
[modify] https://crrev.com/2ad2a9bf7205ec77843cf27a7964fda92df386b2/third_party/WebKit/Source/core/svg/SVGPatternElement.cpp
[modify] https://crrev.com/2ad2a9bf7205ec77843cf27a7964fda92df386b2/third_party/WebKit/Source/core/svg/SVGPatternElement.h
[modify] https://crrev.com/2ad2a9bf7205ec77843cf27a7964fda92df386b2/third_party/WebKit/Source/core/svg/SVGSVGElement.cpp
[modify] https://crrev.com/2ad2a9bf7205ec77843cf27a7964fda92df386b2/third_party/WebKit/Source/core/svg/SVGSVGElement.h

Should we raise a spec issue to get a clarification on the display:none question Fredrik?

Filed https://github.com/w3c/svgwg/issues/307

Note that the test from r451938 is failing with --site-per-process (i.e., when using out-of-process iframes for cross-site URLs).  Please see  issue 697111 .

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

I'm not sure it's worthwhile to keep this around while waiting for WG resolution and DOMMatrix to be usable here (i.e issue 709001.) I even STR that we have another bug for the display:none behavior. Shout if you disagree Paul.

If the origin issue has been resolved (your patch has been merged right?). Then I am good.