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

RESOLVED DUPLICATE of bug 377085

Status

()

--
major
RESOLVED DUPLICATE of bug 377085
12 years ago
11 years ago

People

(Reporter: a.neumann, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

12 years ago
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.
(Reporter)

Comment 2

12 years ago
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.

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

Comment 4

11 years ago
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/ ?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 377085
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.
You need to log in before you can comment on or make changes to this bug.