Last Comment Bug 649285 - object tag including a SVG will have offsetWidth and offsetHeight set to 0 when DOMContentLoaded fires
: object tag including a SVG will have offsetWidth and offsetHeight set to 0 wh...
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: 4.0 Branch
: x86_64 Linux
-- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
  Show dependency treegraph
Reported: 2011-04-12 04:05 PDT by Trygve Lie
Modified: 2013-05-22 02:55 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

try to get the size of the inline svg in firefox (2.25 KB, text/html)
2013-05-06 08:22 PDT, herrernst
no flags Details

Description User image Trygve Lie 2011-04-12 04:05:21 PDT
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.
Comment 1 User image Trygve Lie 2011-04-12 04:07:02 PDT
FF vs "other browsers" can be seen here:
Comment 2 User image aravindm 2011-04-12 04:22:46 PDT
Confirmed on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110411 Firefox/4.2a1pre
Comment 3 User image Kyle Simpson 2011-04-12 05:23:47 PDT
Confirmed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Comment 4 User image George Carstoiu 2011-04-26 09:36:46 PDT
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
Comment 5 User image Kyle Simpson 2011-04-26 09:43:51 PDT
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".
Comment 6 User image Trygve Lie 2011-04-26 10:34:53 PDT
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.
Comment 7 User image Kyle Simpson 2011-04-26 10:39:05 PDT
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.
Comment 8 User image Trygve Lie 2011-04-28 02:06:21 PDT
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.
Comment 9 User image George Carstoiu 2011-05-20 07:55:47 PDT
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.
Comment 10 User image Clément Hallet 2012-07-11 06:06:55 PDT
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"
Comment 11 User image Robert Longson 2012-09-04 05:50:47 PDT
They are not part of SVG. According to they are HTMLElement things. You won't find them in the SVG specification.
Comment 12 User image Matthew Woehlke 2012-09-28 16:58:29 PDT
How then is one supposed to determine the size of an SVG element in a web page?
Comment 13 User image Robert Longson 2012-09-28 23:03:58 PDT
getBBox().width and getBBox().height
Comment 14 User image herrernst 2013-05-06 08:20:41 PDT
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.)
Comment 15 User image herrernst 2013-05-06 08:22:01 PDT
Created attachment 745884 [details]
try to get the size of the inline svg in firefox
Comment 16 User image herrernst 2013-05-06 08:32:00 PDT
I have also uploaded it here:
Comment 17 User image Robert Longson 2013-05-14 05:35:59 PDT
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.
Comment 18 User image herrernst 2013-05-15 08:29:40 PDT
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.
Comment 19 User image Robert Longson 2013-05-15 08:34:10 PDT
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.
Comment 20 User image herrernst 2013-05-16 07:24:46 PDT
> 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?

Comment 21 User image Robert Longson 2013-05-16 09:55:52 PDT
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.
Comment 22 User image herrernst 2013-05-22 02:55:00 PDT
You are right, a have raised a new issue as bug 874811, thanks for your patience.

Note You need to log in before you can comment on or make changes to this bug.