369400 - .getBBox() returns wrong values when called on an object in a nested svg element with viewBox

Status: RESOLVED DUPLICATE of bug 377085

(Core :: SVG, defect)

Description

[Andreas Neumann]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a2pre) Gecko/20070205 Minefield/3.0a2pre
Build Identifier: Firefox 1.5 to Firefox 3

In the given example a rectangle with red stroke indicating the bounding box of the path element should be drawn. Additionally, an alert box displays the bbox values.

In Firefox 1.5 to 3, the returned values are wrong. They are not in the viewBox range. In Firefox 3 the path is not even rendered at the time of writing (2007-02-05).

Reproducible: Always

Steps to Reproduce:
1. load the example
2. check if the rectangle with the red stroke appears and matches the bbox of the path element
3. check the values alerted
Actual Results:  
incorrect bbox values

Expected Results:  
correct bbox values in the coordinate system of the element where .getBBox() was called.

Comment 1

[tor]

The incorrect values appear to be the usual cairo limited range problem - if you divide all the coordinates in the testcase by 100 then the bbox values are as expected.

Comment 2

[Andreas Neumann]

hm - yes. Does this mean that I have to change all my mapping examples because of this cairo limitation? These coordinate range problems don't appear in other implementations (Opera, Safari, Batik, ASV), well, they do appear, but at other threshold values.

This approach with the high viewBox values is unfortunately quite commonly used, by me and other people, because it is convenient. If Cairo doesn't change then I have to find a different script solution to handle the problem. Do you have any insight on Cairo's plans?

It is funny, because the rendering always seems ok, but certain DOM functions don't work any more with the extreme viewBox values.

Comment 3

[Jonathan Watt [:jwatt]]

Andreas, can you take another look at this using an up to date trunk build? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ This seems fixed in trunk builds now, probably due to the cairo fixed point change.

Comment 4

[Andreas Neumann]

hm, the problem still exists. Tested with "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007112605 Minefield/3.0b2pre", also with the Linux version.

I had an older install and updated with "Check for Updates" - does this procedure result in the latest trunk like downloading and installing from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ ?

Comment 6

[Jonathan Watt [:jwatt]]

Hah. The reason I thought this bug was fixed is because I'm running with the fix for bug 377085 in my builds. I guess I can confirm the patch there fixes this bug. ;-)

> I had an older install and updated with "Check for Updates" - does this
> procedure result in the latest trunk like downloading and installing from
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ ?

Yes. 3.0b2pre is current trunk.