Closed Bug 543965 Opened 11 years ago Closed 11 years ago
CTM on outer SVG element returns null instead of an instance of SVGMatrix
Can you use the Add an attachment link above to add your testcase please rather than posting the code inline in the bug comment?
Assignee: nobody → longsonr
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
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.
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.
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: 11 years ago
Resolution: --- → INVALID
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.