User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20100101 Firefox/5.0
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20100101 Firefox/5.0
I am using a inner <svg> element (lets call it 'inner-svg') in my web app to control positioning of a bunch of children. To make my life easier I have been using a lot of percentage based coordinates.
In the attached testcase I have a example of the kind of behaviour I want. The inner-svg element controls the whole size for a bunch of dependent children. All the children's coordinates are specified using percentages.
I noticed that when I re-size inner-svg by changing the width / height attribute that rect, line, etc update using the new coordinate space. However <text> nodes don't.
Steps to Reproduce:
1. View attachment
2 [review]. Click the 'Update Inner SVG' button
The red square re-sizes & positions properly. The bottom right text does not and falls 'outside'.
The bottom right text should move to be inside the red square.
Chrome seems to be worse. :-)
Created attachment 541806 [details]
SVG Text positioning bug example
I can reproduce with older builds, but this works for me on trunk. Looks like it got fixed in this range 3 days ago: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a285146675dc&tochange=b7a93f1279b7
But the only sorta-related thing in that range is bug 652832 and even that's a stretch...
If this is fixed in trunk should this bug be closed?
Well, it would be good to understand whether it's really fixed or whether just the testcase you attached happens to work now for some semi-unrelated reason.... Going to wait for one of the SVG folks to look at this to tell which it is.
(In reply to comment #2)
> But the only sorta-related thing in that range is bug 652832 and even that's
> a stretch...
I confirmed with a local backout that that bug's cset (30c1b4519b2a) fixed the attached testcase.
(Robert, does it make sense that your commit fixed this?)
bug 652832 makes nsSVGLength2::SetBaseValueString call nsSVGlement::DidChangeLength. This is overridden in nsSVGSVGElement and that override expects to be called when the length changes as it does here.
I'll write a test for this.
Reftest, that is.
Created attachment 541919 [details] [diff] [review]
If you're going to write tests then neither nsSVGEnum, nor SVGPreserveAspect ratio work for the same reason (see patch). nsSVGSVGElement and nsSVGMarkerElement override these methods and when DOM setAttribute is called the overrides need to be called too.
Comment on attachment 541919 [details] [diff] [review]
In the end I moved the first part to bug 687340 and decided the second part (the enum change) was not required as bug 687340 removes all enum overrides.
Brian wrote mochitests that cover this now.