Closed Bug 649285 Opened 12 years ago Closed 11 years ago

object tag including a SVG will have offsetWidth and offsetHeight set to 0 when DOMContentLoaded fires


(Firefox :: General, defect)

4.0 Branch
Not set





(Reporter: mozilla, Unassigned)





(1 file)

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0

If a object tag includes a SVG files the offsetWidth and offsetHeight will be 0 when DOMContentLoaded fires even if the object tag has a set width / height.
Example can be seen here:

If the same values are read when onload fires the values are set.
Example can be seen here:

All other "modern" browsers has these values on DOMContentLoaded. FF is the only one returning 0 as value.

Reproducible: Always

Steps to Reproduce:
1. Create a document with a object tag including a svg file. Set a width on the object tag.
2. Create a function which reads out offsetWidth of the object tag.
3. Fire the function created in step 2 at DOMContentLoaded. 
Actual Results:  
The value are 0 and not the actual value of the object tag.

Expected Results:  
The object tag to have a correct value.
FF vs "other browsers" can be seen here:
Confirmed on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110411 Firefox/4.2a1pre
Confirmed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Mozilla/5.0 (X11; Linux i686; rv:6.0a1) Gecko/20110426 Firefox/6.0a1

I am unable to reproduce this issue - the link returns 400
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

I still am able to reproduce it. In the "domcontentloaded" test, I see "0" and "400", where it should be "400" and "400".
George: Seems like your running FF6. If so this might not be a problem in a upcomming release. Which is good. 

I'll test version 6 when I get off mobile roaming (I'm out traveling at the moment) and can download it on a land connection tomorrow.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:6.0a1) Gecko/20110425 Firefox/6.0a1

I just tried it in FF6 (nightly) on windows, and it still fails for me.
Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110427 Firefox/6.0a1

Just tested in FF6 (nightly) on Ubuntu and it still fails here also.
Version: unspecified → 4.0 Branch
Mozilla/5.0 (X11; Linux i686; rv:6.0a1) Gecko/20110520 Firefox/6.0a1

Tested it again and received 0.

Marking issue as New.

Bug present ever since 3.6.17.
Ever confirmed: true
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20100101 Firefox/13.0.1

This bug is still present, except the value is now "undefined"
They are not part of SVG. According to they are HTMLElement things. You won't find them in the SVG specification.
Closed: 11 years ago
Resolution: --- → INVALID
How then is one supposed to determine the size of an SVG element in a web page?
getBBox().width and getBBox().height
I am using inline SVG, not an object element, but even then I get no reasonable values. Using getBBox() as suggested does not always return the needed values, because it returns the bounding box for the SVG root element in SVG coordinates (which can be different from the size of the element in CSS pixels, like when you are embedding images or video, which can be scaled).

I have attached a test case. SVGs are great to use in responsive design, because they scale without loss. But if the HTML element is sized different from the SVG canvas, it is nearly impossible in Firefox to get the size of the SVG element (the only means to get a value > 0 is getBoundingClientRect(), but it also doesn't return the size of the SVG element if you change the viewBox to something other than "0 0 $width $height", which seems to be another bug).

jQuery tries to patch this problem in their getWidthOrHeight() function (they also refer to this ticket here), but this also fails in this situation (see test case source).

As others have mentioned already, current versions of Chrome, Safari, Opera and also IE9 (where the only property that doesn't work is offsetWidth()) always return the desired values.

(The only workaround I have found is to set "display: block" on the SVG element and use window.getComputedStyle().width (or jQuery), but clientWidth/offsetWidth are even not working then.)
I have also uploaded it here:
In future it's best to create your own bug since your issue is about getBBox and not offsetWidth, especially as this bug is closed as invalid.

As to your issue, you seem to have the mistaken belief that a viewBox is applied to the <svg> element itself, it isn't it is applied to its children only. See specifically...

If specified, an additional transformation is applied to all descendants of the given element to achieve the specified effect.

It is unfortunate that other browsers get this wrong too but you'd have to complain about their behaviour in their bug tracking systems.
No, my issue is not about getBBox, but about getting the width and height of an <svg> element in CSS pixels in an html page, which this bug is exactly about. (I only included a reference to getBBox because you closed the bug and recommended to use getBBox, which seems to be the wrong API to get the size of an element in an html page nonetheless).

My intent is that this bug is reopened and clientWidth/Height and offsetWidth/Height gets fixed for svg elements.
You should raise that with the w3c style working group via Start your email title with [cssom-view]

If they change the specification we'll likely implement it. As it stands we're implementing what it says.
> As it stands we're implementing what it says.
To exactly which part of which specification are you referring to?

According to CSSOM View Module [1] the client* attributes (amongst others) are extensions to the Element interface, whereas the offset* properties are extensions to the HTMLElement interface. As <svg> does not implement the HTMLElement interface, there is no requirement to support the offset* attributes. But <svg> implements the Element interface, so at least it would be reasonable to support the client* attributes (as only IE does).

So it seems to be a matter of implementing the CSSOM View Module for SVG (as every other major browser has) or not (as you sadly, also seen in your own docs at [2], where it is stated that the client* attributes are only available in HTML). But even then, shouldn't client* be 'undefined' then, and not 0?

Attachment #745884 - Attachment mime type: text/plain → text/html
Well yes but this bug is about offset* and not client* If client* is wrong for SVG raise a new bug, ideally with a testcase.
You are right, a have raised a new issue as bug 874811, thanks for your patience.
You need to log in before you can comment on or make changes to this bug.