Closed Bug 543965 Opened 14 years ago Closed 14 years ago

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

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: laaglu, Unassigned)

References

Details

Attachments

(2 files, 1 obsolete file)

sample to reproduce getCTM problem
708 bytes, text/html
Details
screenCTM
714 bytes, text/html
Details 
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

    
    

    
      
  


  
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

    
    

    
      
  

    
    

    
  
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.

    
    

    
      
  

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached 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: 14 years ago
Resolution: --- → INVALID

        Attachment #425013 -
        Attachment is obsolete: true
Assignee: longsonr → nobody

    
    

    
  
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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: