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

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Trygve Lie]

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:
http://files.trygve-lie.com/tests/object_domcontentloaded/domcontentloaded.html

If the same values are read when onload fires the values are set.
Example can be seen here:
http://files.trygve-lie.com/tests/object_domcontentloaded/onload.html

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

[Trygve Lie]

FF vs "other browsers" can be seen here:
http://files.trygve-lie.com/bugs/ff_object_offset.png

Comment 2

[aravindm]

Confirmed on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110411 Firefox/4.2a1pre

Comment 3

[Kyle Simpson]

Confirmed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

Comment 4

[George Carstoiu]

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

[Kyle Simpson]

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

[Trygve Lie]

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

[Kyle Simpson]

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

[Trygve Lie]

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

[George Carstoiu]

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

[Clément Hallet]

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

[Robert Longson [:longsonr]]

They are not part of SVG. According to http://www.w3.org/TR/cssom-view/#offset-attributes they are HTMLElement things. You won't find them in the SVG specification.

Comment 12

[Matthew Woehlke]

How then is one supposed to determine the size of an SVG element in a web page?

Comment 13

[Robert Longson [:longsonr]]

getBBox().width and getBBox().height

Comment 14

[herrernst]

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

[herrernst]

Attachment: try to get the size of the inline svg in firefox

Comment 16

[herrernst]

I have also uploaded it here: http://jsbin.com/ibijaw/1

Comment 17

[Robert Longson [:longsonr]]

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 http://www.w3.org/TR/SVG/coords.html#ViewBoxAttribute 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

[herrernst]

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

[Robert Longson [:longsonr]]

You should raise that with the w3c style working group via http://lists.w3.org/Archives/Public/www-style/ 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

[herrernst]

> 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?

[1] http://www.w3.org/TR/cssom-view/
[2] https://developer.mozilla.org/en-US/docs/Web/API/element

Comment 21

[Robert Longson [:longsonr]]

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

[herrernst]

You are right, a have raised a new issue as bug 874811, thanks for your patience.