667064 - SVG: text elements inside a <svg> element

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Séamus O'Connor]

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.

Reproducible: Always

Steps to Reproduce:
1. View attachment
2 [review]. Click the 'Update Inner SVG' button

Actual Results:  
The red square re-sizes & positions properly. The bottom right text does not and falls 'outside'.

Expected Results:  
The bottom right text should move to be inside the red square.

Chrome seems to be worse. :-)

Comment 1

[Séamus O'Connor]

Attachment: SVG Text positioning bug example

Comment 2

[Boris Zbarsky [:bzbarsky]]

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...

Comment 3

[Séamus O'Connor]

If this is fixed in trunk should this bug be closed?

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.

Comment 5

[Daniel Holbert [:dholbert]]

(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.

Comment 6

[Daniel Holbert [:dholbert]]

(Robert, does it make sense that your commit fixed this?)

Comment 7

[Robert Longson [:longsonr]]

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.

Comment 8

[Jonathan Watt [:jwatt]]

I'll write a test for this.

Comment 9

[Jonathan Watt [:jwatt]]

Reftest, that is.

Comment 10

[Robert Longson [:longsonr]]

Attachment: other fixes

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 11

[Robert Longson [:longsonr]]

Comment on attachment 541919 [details] [diff] [review]
other fixes

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.

Comment 12

[Robert Longson [:longsonr]]

Brian wrote mochitests that cover this now.