Firefox also has problems with SVG in floating divs, but behaves differently: https://bugzilla.mozilla.org/show_bug.cgi?id=1478026

quelbs@ - Thanks for filing the issue...!!

Tried testing the issue by opening a page with an svg in a floating div with style="width:auto;height:auto;". But able to see a blank page only.
Could you please a sample test file/url to test the issue from TE-end. This will help us in triaging the issue further.

Thanks...!!

krajshree@, use the example URL given in #0:
https://bug1478026.bmoattachments.org/attachment.cgi?id=8994528

This behavior is observed since at least Chrome 30, also in Firefox.

@krajshree, in your example the results is displaying the SVG with a size of 0x0 thus you see a "blank page" although it is not blank. Having an invalid html file causing chromium to be in "quirks mode", results in even more faulty displayings than in a valid html file I attached in the corresponding Firefox bug with the example link. And now also here as an attachment.

Deleted: svg_test.html 2.7 KB

svg_test.html 2.7 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Verified. Another intrinsic sizing issue for SVG.

It's more of a general replaced element issue (it just so happens that using an SVG image is the only way you can currently produce something with an intrinsic ratio but lacking intrinsic width and height) - maybe shrink-to-fit?

Is the thing I attach here a good minimal test case?

Deleted: tc.html 321 bytes

tc.html 321 bytes View Download

Yes, seems like it (with possible reservation for the pass condition =))

What's wrong with it?

Possibly nothing, I'm not sure that the width would end up resolving to 100px though. But maybe it will.

Better find out before we attempt to fix it. :)

Actually, the only browser I've found to display anything at all with this test, is Edge, which does 300x300. That may make more sense than 100x100, I guess? I.e. using the 300px fallback for width [1], and resolving height based on intrinsic ratio (1:1)?

https://www.w3.org/TR/CSS22/visudet.html#inline-replaced-width

Yes, I guess that might make some sense (at least as much sense as the 300x150 dimensions usually make...)

While looking at another bug it dawn on me why the last three get a used width of 150px - LayoutImage uses LayoutImageResource::ImageSize which in turn uses ImageResourceContent::IntrinsicSize - which doesn't really return a correct intrinsic size in this case... So we get a preferred width of 150px because of that. With that fixed I suspect we would render the same as Gecko.