987629 - Size of svg ignored when embedded through <object> or <img>

Status: UNCONFIRMED

(Core :: SVG, defect)

Description

[David Vest]

Attachment: style-on-svg-root-ignored.html

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36

Steps to reproduce:

Load attached demo.


Actual results:

A green 300x150 rectangle is shown.


Expected results:

100x100 green rectangle.

Size of svg root box is ignored and 300x150 (the fallback size) used instead, for object, svg and rect.

Comment 1

[David Vest]

This example came up in https://code.google.com/p/chromium/issues/detail?id=308992#c13 where we try to align SVG sizing in Firefox and Blink. We're not sure the current Firefox behavior is correct nor useful. What do you think?

Cameron, ed(at opera.com) told me to add you to cc. If you know of someone else within Mozilla this suits better, feel free to redirect.

Comment 2

[David Vest]

I have two questions:

 * If width/heigth of svg elements are presentation attributes, should the intrinsic size from an embedded svg come from only the width/height attributes, and not style?

 * Should the root svg element (the svg viewport) always be the same size as the referencing element? Browsers disagree on this point. Opera/presto and IE allows them to diverge, Firefox keeps them together, even if it means ignoring specified style on the svg root.

Comment 3

[Daniel Holbert [:dholbert]]

Firefox's inconsistency between viewed-directly vs. embedded-in-<object> definitely seems iffy.

(See also bug 668163 and bug 850952, which were about related (but maybe different) width/height attribute-vs-property issues, FWIW.)

Also, the intrinsic size of an outer <svg> is computed in nsSVGOuterSVGFrame::GetIntrinsicSize():
http://mxr.mozilla.org/mozilla-central/source/layout/svg/nsSVGOuterSVGFrame.cpp?rev=ac6b0bcdea0b#160

...which says this:
> 163   // XXXjwatt Note that here we want to return the CSS width/height if they're
> 164   // specified and we're embedded inside an nsIObjectLoadingContent.

...which dates back to 2007 (bug 294086). I suspect if we addressed that, we'd produce David's expected results on his testcase.

Comment 4

[David Vest]

Daniel, thanks for bringing up bug 294086. I hadn't read that bug before. https://bugzilla.mozilla.org/show_bug.cgi?id=294086#c34 might be of interest to this bug, indicating current behavior is probably intentional.