SVGLocatable::getCTM on outer SVG element returns null instead of an instance of SVGMatrix

RESOLVED INVALID

Status

()

defect
RESOLVED INVALID
10 years ago
10 years ago

People

(Reporter: laaglu, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Reporter

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100110 Mandriva Linux/1.9.1.7-0.1mdv2010.0 (2010.0) Firefox/3.5.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)

Since FF3.6, getCTM seems broken. The following page will display the SVGMatrix on FF3.5.x, Opera 10.x, Chrome 4.x but displays null on FF3.6

<html>
<head>
<script type="text/javascript">

function setup() {
 var data = '<svg width="400px" height="200px" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">' +
'<ellipse stroke-width="1" fill="red" cx="100" cy="50" rx="50" ry="25"/>' +
'</svg>';
 var parser = new DOMParser();
 var svgDocument = parser.parseFromString(data, "text/xml");
 var svgElement = document.importNode(svgDocument.documentElement, true);
 var drawing = document.getElementById("drawing");
 drawing.appendChild(svgElement);
 alert(svgElement.getCTM());
}
</script>
</head>
<body onload="setup()">
<p>Here is an html paragraph. And below is a svg drawing</p>
<div id="drawing"></div>
</body>
</html>


Reproducible: Always

Steps to Reproduce:
1. Save html/svg sample contained in the details section in a .html file and open the file with FF3.6


Actual Results:  
An alert displaying "null" is displayed

Expected Results:  
An alert displaying [object SVGMatrix] was expected

The problem can be reproduced on linux as well
Can you use the Add an attachment link above to add your testcase please rather than posting the code inline in the bug comment?
Reporter

Comment 2

10 years ago
Posted patch patch (obsolete) — Splinter Review
Assignee: nobody → longsonr
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #425013 - Flags: review?(jwatt)
Keywords: regression
Summary: Regression. SVGLocatable::getCTM returns null instead of an instance of SVGMatrix → SVGLocatable::getCTM on outer SVG element returns null instead of an instance of SVGMatrix
Looks to be a regression from bug 366697

Does this look like the right approach Ryo?
Blocks: 366697
I'm not really sure what to do about this bug just yet. As I recall, we
previously tried to include some offset to the nearest containing block, or to
the client area (I can't recall which). The problem is that the behavior isn't
specified in the spec, there are conditions under which it didn't make sense, and by trying to be "clever" and include offsets in inline SVG we were always at risk of tripping people
up with unexpected and undesirable behavior. Return null actually seems to prevent too much new content from being created that may
rely on "weird" behavior that a future version of the spec may change. (An alternative would be to throw an exception.)

I'm not very keen on returning a singular matrix as an alternative to the past
and present behavior. Returning null or throwing draws content authors'
attention to the issue early, but a singular matrix may not show problems until
much later in a script's execution, making it harder for authors to figure out
what went wrong.

Ultimately this issue is on a very long list of things that the SVG WG needs to
discuss and fix up in SVG 2.0. For now though, I wonder if we shouldn't just leave it as it is.
The patch doesn't make us return a singular matrix in this case. We return a unit scaling matrix with a translation of something like (8, 44).

Note that nsSVGSVGElement::GetCTM converts any singular matrices to null so that's what we return in the unpatched code.
Oops, I read it backwards. :-)

I'd still be glad of feedback regarding whether we should revert to our old buggy behavior or wait for the WG to define things more fully.
Posted file screenCTM
If you replace getCTM by getScreenCTM you get a matrix. We should at least be consistent about whether these work or they don't at the moment we're just weird.
Attachment #425013 - Flags: review?(jwatt)
Rereading the spec http://www.w3.org/TR/SVG/types.html#InterfaceSVGLocatable I agree with you Jonathan. Expecting anything from getCTM called on the outermost SVG element is nonsense as it doesn't have a nearestViewportElement.

Lukas, you may find that calling getScreenCTM gives you what you want.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Attachment #425013 - Attachment is obsolete: true
Assignee: longsonr → nobody
Reporter

Comment 10

10 years ago
Actually I am writing a GWT library to encapsulate SVG implementations from various browsers (http://www.vectomatic.org/libgwtsvg). 
One of the samples demonstrating the library is a chess game UI (http://www.vectomatic.org/libgwtsvg-chess). 
It broke in the transition between FF3.5 and FF3.6, which is why I opened the bug.

Using getScreenCTM seems indeed like the right thing to do. It works fine on all SVG enabled browsers, so I should be able to fix my sample soon. 

Regarding the behavior of getCTM, most other browsers (Opera 10.10, Chromium 4.0.203 and FF3.5) seem to return the same matrix as getScreenCTM when you call getCTM on the root element. 
If FF3.6 behaves differently, there is a risk of somebody making the same mistake as I and deploying a page they tested only with Chromium and which would not display in FF. Not a big risk I agree.
To get a consistent behavior across all browsers in libgwtsvg, I can add a test for other browsers and return null if getCTM is called on the root element. But if you can revert to the FF3.5 behavior, the better

Many thanks for your time and expertise anyway
(In reply to comment #10)
> To get a consistent behavior across all browsers in libgwtsvg, I can add a test
> for other browsers and return null if getCTM is called on the root element. But
> if you can revert to the FF3.5 behavior, the better
> 

We think the 3.5 behaviour was wrong so we won't be reverting to it :-)
Also, from what I remember, when the SVG Working Group last looked at this issue the implementations were inconsistent in many cases (depending on the markup/styling "outside" the <svg> element). The SVG WG will certainly be looking at it again as part of the work on SVG 2.0, after which Mozilla will fix up the undefined behavior to do whatever the new spec requires.

Thanks for your bug report Lukas. It's good to know that someone *has* tripped over this.
You need to log in before you can comment on or make changes to this bug.