User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150506030206 Steps to reproduce: 1. Open http://jsbin.com/jecuca/edit?html,output Actual results: Nothing appear. Open Inspector and selecting <svg> indicates that it's 0x0. Expected results: Blink, Trident, WebKit renders the <rect> fit to the page. Sorry I neglected to narrow this down to the root cause...

The basic issue here is that in an example like this, the <svg> element's size has been specified as a percentage; but its containing block wants to size itself according to its contents ("shrink-wrap"). So it calls GetPrefISize() on its child, the nsSVGOuterFrame; that child sees that it has a percentage width, and returns 0 as it doesn't know what to use as a basis for the percentage: http://hg.mozilla.org/mozilla-central/file/e537a1ba501b/layout/svg/nsSVGOuterSVGFrame.cpp#l173 In effect, we're getting a similar result to what you'd get if you put an SVG image with width/height specified as percentage inside a block with width:-moz-fit-content. In this case, at least, the comment in the code suggests that this is undefined per spec -- and so whatever we do is in some sense OK. But I think perhaps we could do something more helpful/less unexpected than collapsing to zero, especially for the example within an orthogonal block, where it's not at all obvious to the author that the SVG won't know how to size itself.

Here's a (slightly simplified) standalone testcase based on the jsbin example. Note how the blue-bordered <div> collapses to zero height when its writing mode is set to vertical. It's also interesting to compare Chrome's behavior on this testcase. It seems to give the <svg> and its containing <div> an arbitrary size (at least, I don't see any obvious explanation for the size it picks; haven't tried to read the blink code and figure it out), but doesn't collapse it to zero.

This is modifying behavior that (according to our code comments, at least) is undefined, so it's not at all clear what's "right" to do, but something like this seems to result in more useful behavior in my testing so far, at least. jwatt, do you think it's reasonable to do something like this?

Note that the proposed patch here will also affect behavior in cases that don't involve vertical writing mode, if they venture into the (undefined) territory of percentage sizes within a container using -moz-fit-content; see this example. But I don't think that's necessarily a bad thing. There's no existing standard or interop, AFAIK (Chrome certainly behaves quite differently from Firefox with this example), and I don't see any real value to our existing behavior.

https://hg.mozilla.org/integration/mozilla-inbound/rev/4f8b9b50cd9362cfbf83a679a64cb5903c4661f8 Bug 1162418 - Try to find a suitable non-zero dimension to use when containing block's inline-size depends on an SVG element which is specified as a percentage of its container. r=jwatt

The patch in this bug doesn't make sense, as I described in bug 1340715.