Bug 16075 - setRotate method in SVGTransform does apparently nothing.
Summary: setRotate method in SVGTransform does apparently nothing.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: javascript:alert(function(){g=documen...
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-20 13:35 PST by David Jones
Modified: 2008-02-08 15:49 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Jones 2007-11-20 13:35:21 PST
JavaScript programs are supposed to be able to mutate a transform within a transform list (for example, the transform list I create with <g transform="translate(1 2) rotate(3)" /g>) using various methods in the SVGTransform DOM, see:

http://www.w3.org/TR/SVG/coords.html#InterfaceSVGTransform

The bookmarklet is supposed to produce an alert showing "rotate(10)" (which it does on Firefox), but on Safari it shows "rotate(90)".  The JavaScript creates a g element with a transform list of "rotate(90)" then tries to use the setRotate method to change it to "rotate(10)".  The value of the transform attribute after the call is alert'd.

I'm pretty sure I first noticed this on the setMatrix method (so that's probably not implemented either), but that's not what my JavaScript example tests.

On the nightly WebKit build that I downloaded whenever.
Comment 1 Eric Seidel (no email) 2007-11-20 14:03:27 PST
 I have confirmed this does not work on TOT.  I think setRotate should work on SVGTransform, it just probably doesn't update the actual list.
Comment 2 Nikolas Zimmermann 2008-02-03 08:37:57 PST
Hi David,

Hm, I'm not entirely sure about the testcase. You are modifying transform.baseVal.. and checking the result of the 'transform' attribute. using"g.transform.baseVal.getItem(0).angle;" gives the desired angle of 10.

The question is wheter the transform _attribute_ should reflect changes of SVGAnimatedTransformList done using SVG DOM. I couldn't find a hint in the SVG 1.1 spec - had a quick look. The only attribute which I'm aware of that gets synchronized is the 'points' attribute from <polygon> / <polyline>. Quote:

"Additionally, the 'points' attribute on the original element accessed via the XML DOM (e.g., using the getAttribute() method call) will reflect any changes made to points." (SVGAnimatedPoints documentation)

Neither SVGAnimatedTransformList / SVGTransformList nor SVTransform demand the same behaviour like the 'points' attribute. Please check twice, this is valid SVG 1.1 :-)

Greetings,
Niko
Comment 3 David Jones 2008-02-08 13:36:38 PST
(In reply to comment #2)
> Hm, I'm not entirely sure about the testcase.

Hm, I see there might be problems with that testcase.  Here's another:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html 
  PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>WebKit bug 16075</title>
</head>
<body>
<svg version="1.1"
     xmlns="http://www.w3.org/2000/svg">
  <g transform='rotate(10)' id='b'>
  <text x='50' y='50' font-size='20' fill='red'>
    Bob
  </text>
  </g>
</svg>
<script>
g=document.getElementById('b')
g.transform.baseVal.getItem(0).setRotate(0, 50, 50)
</script>
</body>
</html>

The plain SVG draws the text "Bob" rotated at a smallish angle (10 degrees).  The script then attempts to change the rotation to 0 so that the text should be displayed level (horizontally).

Safari: text is rotated.
Firefox: text not rotated.

This suggests that setRotate has apparently no effect.

Is this testcase any more useful?

All this attribute synchronisation stuff is quite interesting but I don't consider it germane to this bug.  It was a mistake to rely on the attributes for the original testcase.

Of course, one might consider that it's a bug that it works in Firefox and not in Safari.
Comment 4 Nikolas Zimmermann 2008-02-08 15:10:28 PST
Hi again,

> Hm, I see there might be problems with that testcase.  Here's another:
thanks for your work, that testcase is valid :-)
 
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE html 
>   PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml">
> <head>
> <title>WebKit bug 16075</title>
> </head>
> <body>
> <svg version="1.1"
>      xmlns="http://www.w3.org/2000/svg">
>   <g transform='rotate(10)' id='b'>
>   <text x='50' y='50' font-size='20' fill='red'>
>     Bob
>   </text>
>   </g>
> </svg>
> <script>
> g=document.getElementById('b')
> g.transform.baseVal.getItem(0).setRotate(0, 50, 50)
> </script>
> </body>
> </html>
> 
> The plain SVG draws the text "Bob" rotated at a smallish angle (10 degrees). 
> The script then attempts to change the rotation to 0 so that the text should be
> displayed level (horizontally).
> 
> Safari: text is rotated.
> Firefox: text not rotated.
> 
> This suggests that setRotate has apparently no effect.
> 
> Is this testcase any more useful?
Yes much better - this is fixed in Safari trunk since some days.
All dynamic updating should work faster now!

> All this attribute synchronisation stuff is quite interesting but I don't
> consider it germane to this bug.  It was a mistake to rely on the attributes
> for the original testcase.
The SVG attribute synchronisation is interessting for sure, but it's not spec'ed - and I'm not sure wheter SVG DOM changes should be represented in the attribute values.

> Of course, one might consider that it's a bug that it works in Firefox and not
> in Safari.
You mean the attribute synchronisation or the testcase you posted?
The testcase is valid, and it's fixed now. The attribute sync is not implemented and it's unlikely that we'll do that, unless specified by SVG 1.1

Thanks for your help,
closing bug now!

Please try more cases like this - I'm always interessted in 'dynamic update' bugs.

Greetings,
Niko
Comment 5 David Jones 2008-02-08 15:49:32 PST
(In reply to comment #4)
> 
> > Of course, one might consider that it's a bug that it works in Firefox and not
> > in Safari.
> You mean the attribute synchronisation or the testcase you posted?

I meant the attribute synchronisation.  Generally I don't care about the attribute synchronisation stuff, but I had the feeling that if Firefox did it then you wanted WebKit to do it.

Anyway, thanks for fixing the bug!