1610093 - SVG getScreenCTM does not return correct position if parent is transformed

Status: RESOLVED FIXED

(Core :: SVG, defect, P3)

Description

[kris]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36

Steps to reproduce:

1. open this fiddle
   https://jsfiddle.net/kzima/h0cqbeka/
2. Notice console log having wrong position

Actual results:

getScreenCTM() does not take to account parent's transform and shows wrong point position within SVG coordinate system.

Expected results:

getScreenCTM() should offset parent's transform so the point within coordinate system is correct.

Comment 1

[kris]

This bug is related to https://bugzilla.mozilla.org/show_bug.cgi?id=972041

Comment 2

[Lisa]

H

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to kris from comment #0)

Steps to reproduce:

1. open this fiddle
   https://jsfiddle.net/kzima/h0cqbeka/
2. Notice console log having wrong position

For the record -- I didn't see any position at all in the web console, and then I realized there's a missing step here:

Step 1.5: Click the red square.

After doing that, I see something like this in the Web Console, in Firefox Nightly:

Should print (67, 40), actual value: (117, 90)

(Whereas in Chrome, the should/actual values match.)

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (reporter's testcase, lightly edited)

Here's the testcase, taken from jsfiddle, FWIW.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: reference case 1 (just moved the transform styling from #container to svg)

Here's a version of the testcase where I moved the transform styling from the #container to the svg element. With that change, we get EXPECTED RESULTS.

So: I think this is indeed a bug. Thanks for the report!

Comment 7

[Karl Dubost💡 :karlcow]

Duplicate of bug 1446011 ?

Comment 8

[Daniel Holbert [:dholbert]]

I don't think so, though I'm not entirely sure what that bug covers. Its initial comment references an inter-engine disagreement in interpretation, which we'd like to address, and I'm not sure what the details of that particular disagreement are. I'll mark it as a dependency to establish a relationship, at least, and we can dupe later if appropriate.

(In bug 1446011 comment 1, Robert mentioned bug 972041, whose description sounds quite similar to this issue (though that one's fixed, so it's not exactly a dupe). Anyway -- that bug was not considered a dupe of bug 1446011, so it seems like this one probably is not either.)

Comment 10

[Erik Demaine]

In case it's helpful, here's a more visual illustration of the bug: http://jsfiddle.net/edemaine/vLjd1pa7/6/
The fiddle is based on an old Webkit bug (everything now works fine in Chrome): https://bugs.webkit.org/show_bug.cgi?id=96361
I also found that putting the transform on the <svg> element worked fine, but putting it on the parent doesn't work.
This makes it difficult to make interactive SVG interfaces that need to translate mouse events into SVG coordinate space.

Comment 11

[Timothy Nikkel (:tnikkel)]

Attachment: svg.diff

This fixes the testcase in this bug but it fails dom/svg/test_getCTM.html. I'm uploaded this for someone else to take over the finish line, I'm not planning to work on this further.

Comment 12

[Timothy Nikkel (:tnikkel)]

Attachment: svg2.diff

This is my stab in the dark to try to fix the test failure caused by the first patch, it didn't work, but it seems like it would be correct.

Comment 13

[ulima.ums]

I investigated the failing test together with Timothy and what we found is, that the test case seems to be wrong.

Here is why:

• my own math gives the same result as the patched version
• NOT using an iframe to load the SVG but putting it directly into the dom gives the same result as the patched version. That means,by simply loading the SVG in an iframe the test result change in the unpatched version. And that should not happen
• Chrome gives the same result for the patched version (when loaded via iframe. Funny enough, chrome gives completely different results when loading the SVG without iframe so they seem to have a similar problem - but backward)

Therefore I vote for changing the test and landing the patch

Comment 14

[ulima.ums]

The failing test is in L116 of dom/svg/test/test_getCTM.html => https://searchfox.org/mozilla-central/rev/8f4c180b87e52f3345ef8a3432d6e54bd1eb18dc/dom/svg/test/test_getCTM.html#101
The correct values should be e=-4 and f=19

The calculation behind that is rather straight forward:

e	f	contribution
11	22	SVG root viewbox
3	4	transform of g
1	2	nested svg x and y
30	40	position of foreignObject
1	1	transform of foreignObject
-50	-50	viewbox of target
-4	19	Result

Comment 15

[Robert Longson [:longsonr]]

The code certainly looks about right. Happy to review formally.

Comment 16

[Robert Longson [:longsonr]]

https://treeherder.mozilla.org/jobs?repo=try&revision=9f660edd3cccfdd9e7750b1dc9e59798191f1577

Comment 17

[Robert Longson [:longsonr]]

Attachment: Bug 1610093 - Fix getScreenCTM when parent is transformed. r=emilio

Comment 18

[Robert Longson [:longsonr]]

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

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6c172ec3a6db
Fix getScreenCTM when parent is transformed. r=emilio

Comment 20

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/45165 for changes under testing/web-platform/tests

Comment 21

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/6c172ec3a6db

Comment 22

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot