SVG: text elements inside a <svg> element

RESOLVED FIXED in mozilla7



6 years ago
6 years ago


(Reporter: Séamus O'Connor, Assigned: jwatt)


Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



6 years ago
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

6 years ago
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:

But the only sorta-related thing in that range is bug 652832 and even that's a stretch...

Comment 3

6 years ago
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?)

Comment 7

6 years ago
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.
Last Resolved: 6 years ago
Depends on: 652832
Resolution: --- → FIXED


6 years ago
Target Milestone: --- → mozilla7

Comment 8

6 years ago
I'll write a test for this.
Ever confirmed: true
Flags: in-testsuite?
OS: Mac OS X → All
Hardware: x86_64 → All
Resolution: FIXED → ---

Comment 9

6 years ago
Reftest, that is.
Assignee: nobody → jwatt

Comment 10

6 years ago
Created attachment 541919 [details] [diff] [review]
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.
Attachment #541919 - Flags: review?


6 years ago
Attachment #541919 - Flags: review? → review?(jwatt)


6 years ago
Attachment #541919 - Flags: review?(jwatt) → review+

Comment 11

6 years ago
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.
Attachment #541919 - Attachment is obsolete: true

Comment 12

6 years ago
Brian wrote mochitests that cover this now.
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.