Closed Bug 460946 Opened 13 years ago Closed 13 years ago
the dims returned by get
Bounding Client Rect on rotated svg Element with stroke is incorrect
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1 (.NET CLR 3.5.30729) the dims returned by getBoundingClientRect on rotated svgElement with stroke is incorrect - exactly twice the correct value for width on a rotate of 45° Reproducible: Always Steps to Reproduce: 1.rotate and svg rect with stroke 2.call getBoundingClientRect Actual Results: you see the results on the provided url Expected Results: correctly reported dims
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: General → SVG
Product: Firefox → Core
QA Contact: general → general
just noticed the similar behavior with other kinds of transform too (matrix, skew and translate)
Would you care to attach a translate example? It might be easiest to debug as it has the simplest maths.
After looking more to my translate problem I found that I may be not a bug at all: http://localhost/go2ghana.net/httpdocs/devel/svg/translate.php loads another svg file (http://go2ghana.net/devel/svg/svg/welcomeT.svg) into my editBox container (g element) After applying a transform translate to the root group of the loaded svg I expected the editBox container to grow by the amount of the translate of its child. this seems to be not correct or should it grow?
URLs on localhost are not very useful I get document not found with this: http://go2ghana.net/httpdocs/devel/svg/translate.php
sorry - already the same mistake - the url is http://go2ghana.net/devel/svg/translate.php
The editBox should move, not grow. So translate works.
hmm - I have no build environment setup - can you provide a link to a binary build with the patch?
checked in http://hg.mozilla.org/mozilla-central/rev/132c340c09ff You can get nightly builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ although you might need to wait till tomorrow for the nightly to include this fix.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Hi, unfortunately getBoundingClientRect still gives incorrect results it the svg contains skewed path. If the path is skewed along the x axis the box width is larger than the path width and if skewed along the y axis the box height is too large. See http://go2ghana.net/devel/svg/skewBox.svg
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Please raise a new bug if you have new issues.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Bug 465996 is now fixed, but this bug will still be present and may now actually be worse. See bug 465996 comment 51 for why.
Oh, I didn't see this was an old bug requiring new bugs for further issues before I made that comment.
The original problem is still valid, http://go2ghana.net/devel/svg/demo.php is still wrong in Firefox 3.6.13, 4b7 and 4b8. Works nicely in Chrome 10 dev (broken on Opera 10 also). Please reopen it, I would need a decent svg bounding box for my project :).
You will need to raise a new bug. We only reopen bugs if the patch gets backed out.
You need to log in before you can comment on or make changes to this bug.