1162418 - SVG in vertical flow computes its size to 0x0

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Koji Ishii]

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

Comment 1

[Jonathan Kew [:jfkthame]]

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.

Comment 2

[Jonathan Kew [:jfkthame]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0026e1353196

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: testcase

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.

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: 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

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?

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: writing-mode-free testcase using -moz-fit-content

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.

Comment 6

[Jonathan Kew [:jfkthame]]

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

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/4f8b9b50cd93

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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