780169 - getScreenCTM() fails to account for intermediate <svg> elements

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[jmack]

Example:  http://jsfiddle.net/ps_svg/4x73N/

Steps to reproduce:
Got a point, created from the boundingBox  of an SVG <g> element, transformed it to screen coordinate space and then to user space of the <g> element’s parent using getScreenCTM().

Actual results:
The transform matrix returned by getScreenCTM() is inaccurate (in contrast to the TM that Chrome, IE and FF prior to v13 provide). It seems the viewBox of the intermediate SVGSVGElement is not taken into account.

Expected results:
The correct coordinates of the SVG coordinate space should have been returned (taking into account the intermediate SVGSVGElements viewBox).

Example:  http://jsfiddle.net/ps_svg/4x73N/

The example demonstrates an SVG issue that first appeared in FF v13 and continues in FF v14 plus the FF nightly build (http://nightly.mozilla.org/), as of 8/2/2012.  This demonstration works as expected on FF versions prior to v13, as well as current released versions of Chrome and IE.

Expected Operation:  As you mouse-drag the ellipse the red circle should track the center of the svg group, over the “g” of the ellipse text, “Drag Me.”

Actual operation (starting w/ FF v13): The red circle doesn’t track the center of the svg group.

The problem appears to be related to the transform matrix returned by getScreenCTM(), it doesn’t account for the viewBox of svg element with id  "ProblematicSvgElement".  If this element is removed then the red circle will track the center of the svg group on FF v13+.  However, I have an application that depends on getScreenCTM() working as it did, prior to v13.

Related Bugs marked as fixed in FF v14: 
1) Bug 762411 - getScreenCTM scaling broken on inline embedded 'svg' elements.  However, the issue described above persists in FF v14.
2) Bug 764738 - getScreenCTM method of an SVGSVGElement doesn't take the SVGSVGElement's viewBox into account.  This is marked as a duplicate of Bug 762411.

Comment 1

[Loic]

Mozregression range:

m-c
good=2012-02-17
bad=2012-02-18
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2271cb92cc05&tochange=550779e6bab4

Suspected bug:
Jonathan Watt — Bug 660216, part 3 - getBBox and getCTM on foreignObject should/should not include 'x'/'y' offsets respectively. r=heycam.

Comment 2

[Robert Longson [:longsonr]]

The key part of the testcase is:

<svg>
   <svg id="ProblematicSvgElement" viewBox="100 100 800 800">
      <g id='ellipseGroup' transform="translate(100,100)">
         ...
      </g>
   </svg>
</svg>

And we call getScreenCTM on both the ellipseGroup node and the ProblematicSVGElementNode in getCenter(ele) 

When we call it on ellipseGroup we include the matrix transform that the <svg> element's viewBox applies to its children. We used to include that transform when we called getScreenCTM on the <svg> element itself but we no longer do so after bug 660216 landed.

It seems right that we not include that transform. getScreenCTM gets the transform from the coordinate space that the element's vertices are in, to the "screen" space so to be consistent with the <ellipse> node, the space it's from is the space that cx,cy,rx,ry of the ellipse are in. You can then reliably use that transform to position the element you're calling getScreenCTM on.

What you're suggesting is that it's correct that in this case: <...><svg viewBox="..."><ellipse/></svg></...> getScreenCTM would return the same value on both the <svg> and the <ellipse>
	
What if you want to position the <svg> relative to the "screen"?

Comment 3

[Martin Hejral]

(In reply to Robert Longson from comment #2)
> The key part of the testcase is:
> 
>  <svg viewBox="..."><ellipse/></svg> getScreenCTM **SHOULD** return the same
> value on both the <svg> and the <ellipse>

I think this is correct behaviour... for CONSISTENCY!

By my opinion it is necessary to work with <svg> in the same way as with <g transform=...>

Influence of <svg> for transformation matrix and current user units is exactly the SAME as <g transform=...>!! (not rendered, only container for other objects!)

More in bug 777531, comment 8

Comment 4

[Jonathan Watt [:jwatt]]

(In reply to Martin Hejral from comment #3)
> By my opinion it is necessary to work with <svg> in the same way as with <g
> transform=...>
> 
> Influence of <svg> for transformation matrix and current user units is
> exactly the SAME as <g transform=...>!! (not rendered, only container for
> other objects!)

<svg> does affect rendering, since it creates a clipping area.

Besides that, the viewBox and transform attributes are different. The transform attribute moves the element it's on. The viewBox attribute does not move the element that it is on - it only moves (all) the children of the element that it is on.