972041 - SVG getScreenCTM does not account for CSS transforms

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[MasterLeep]

Attachment: coords.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140127194636

Steps to reproduce:

SVG elements offer the getScreenCTM() function which is documented to return the transformation matrix from user units to the browser's notion of a pixel.  This can be used, for example, when working with coordinates of mouse events.

When SVG elements are contained within HTML elements that have their own CSS transforms specified, the getScreenCTM() does not behave predictably.  Not only do the coordinates no longer transform properly, but the actual matrix returned now varies between browsers.  Without a containing HTML element that has CSS transformations, browsers return the same results.

I believe there is some kind of bug here... so I've created a reduced test case. This file is a reduction from Dungeoneers, an HTML5 game written with a mixture of HTML and SVG.

The test file is linked here - compare the numbers in Firefox and Safari.

http://www.dungeoneers.com/bugs/coords/coords.html



Actual results:

On Firefox 27 and Safari 7, with no CSS transformation applied, the matrix is 0.75; 0; 0; 0.75; 198; 78.  This part is good.
On Firefox 27, with CSS transform applied to the containing field div, the matrix is still 0.75; 0; 0; 0.75; 198; 78 (this seems wrong, it should change.)
On Safari 7, with CSS transform applied, the matrix becomes 0.75; 0; 0; 0.75; 298.625; 169.5.




Expected results:

The bottom line is that getScreenCTM should produce a matrix that maps between SVG coordinate space and mouse space, as specced, regardless of CSS properties on parent html elements.

Note, I'm not sure if Safari's numbers are right or not, but at least they do change in response to external transforms, as would be expected.

Comment 1

[Robert Plante]

I can confirm this occurrence. Safari and Chrome both scale the getScreenCTM() values in accordance with the given (-prefix-)transform: scale(amount); while FireFox does not. On a related note the reason I encountered this to begin with was due to jQuery's offset() returning the wrong value.

Comment 2

[Dan Schultz]

This is indeed happening. Here's a Fiddle that demonstrates the issue: http://jsfiddle.net/danschultz/gRTcF/

Comment 3

[AnSeki.aff]

The "border" of SVG element also seems to make this problem occur.
http://jsfiddle.net/gRTcF/8/

Comment 4

[Robert Longson [:longsonr]]

(In reply to AnSeki.aff from comment #3)
> The "border" of SVG element also seems to make this problem occur.
> http://jsfiddle.net/gRTcF/8/

Probably worth raising that as a separate bug.

Comment 5

[AnSeki.aff]

Yes, I think that `border` differs from `transform`. But I found that `transform` of SVG element also makes this problem occur. And `padding` too.

- http://jsfiddle.net/3v4e0Lnx/
- http://jsfiddle.net/ehy1zkL6/

These may be related, getScreenCTM seems to ignore some CSS properties that changes position.

CSS properties below didn't make this problem:
- `margin`
- `position: absolute`, `left` and `top`
- `overflow: auto` (or `hidden`) of parent and scrolled SVG element
- negative margin
- `padding` of parent

Comment 6

[Robert Longson [:longsonr]]

Please make these comments in a new bug. This one is about transform.

Comment 7

[AnSeki.aff]

Ok, I'm sorry that I didn't understand the rule.

Comment 8

[Fawad Hassan]

I know this bug report is old but it's still not fixed.
https://github.com/d3/d3/issues/2771

Comment 9

[ulima.ums]

We have the same problem in svg.js. All svg libraries kinda depend on this.

I also think that the webkit behavior is incorrect, too.
A rotate or skew of the html element should not only result in `e` and `f` changing.

Comment 10

[violet.bugreport]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a6807ebcfae8abbd4498f53f3d1041b9f6e545bd

Comment 11

[violet.bugreport]

Robert, do you know what is the correct behavior of getCTM() for element inside a display:none?

For example:

<svg id="svg" width="300" height="300">
  <g style="display:none">
    <rect transform="scale(3,3)" id="rec" width="10" height="10"/>
  </g>
</svg>

What should be the return of rec.getCTM()?

The spec says https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsElement__getCTM:

If the current element is a non-rendered element, and the UA is not able to resolve the style of the element, then return null.

I'm not sure what the second half means.

FYI, our transform code heavily relies on the present of a frame, but display:none subtree has no frame. It'd be quite awkward if we need to return the CSS matrix for display:none.

Chrome return CSS matrix for element inside display:none subtree but itself not being display:none.

Comment 12

[Robert Longson [:longsonr]]

We've always basically given up with DOM methods in the face of display:none. bug 376027 covers trying to change that but it's rather hard given you can have a display:none container containing SVG content.

Comment 13

[violet.bugreport]

Attachment: Bug 972041 - getCTM should account for CSS transform

We use nsSVGUtils::GetTransformMatrixInUserSpace to support
CSS transform in getCTM.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bbd172d048d7
getCTM should account for CSS transform r=longsonr

Comment 15

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/bbd172d048d7

Comment 16

[kris]

Thanks for fixing getCTM().

Should the getScreenCTM() be fixed as well?

The use case is translating click event position to SVG coordinate system.
If wrapping container of the SVG is transformed than getScreenCTM() does not take to account parent's offset and the point is displaced by that exact offset in the SVG coordinate system.

Comment 17

[dacbreakpoint]

Referring to kris and his description, I can confirm that the bug still exists and I would be happy if any specialist can take a look. Thank you

Comment 18

[Robert Longson [:longsonr]]

Feel free to raise a new bug with a testcase, this may not be a bug though.

Comment 19

[kris]

@(In reply to Robert Longson [:longsonr] from comment #18)

Feel free to raise a new bug with a testcase, this may not be a bug though.

Hi Robert,

I would rather reopen this bug than creating new one as it relates to this same issue of getScreenCTM() not working properly.

I have created a fiddle to support my test case:
https://jsfiddle.net/kzima/h0cqbeka/

Kind regards,
Kris

Comment 20

[Robert Longson [:longsonr]]

We only reopen bugs if the change they contain gets backed out. If you want something to change, you'll need a new bug.

Comment 21

[kris]

ok, raised a new bug https://bugzilla.mozilla.org/show_bug.cgi?id=1610093