Closed Bug 1162418 Opened 7 years ago Closed 6 years ago

SVG in vertical flow computes its size to 0x0


(Core :: SVG, defect)

Not set



Tracking Status
firefox43 --- fixed


(Reporter: kojii, Assigned: jfkthame)


(Depends on 1 open bug, Blocks 1 open bug, Regressed 1 open bug, )


(Keywords: css3, testcase)


(3 files)

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,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...
Depends on: writing-mode
Ever confirmed: true
Keywords: css3, testcase
Product: Firefox → Core
See Also: → 319163
Component: Untriaged → SVG
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:

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.
Blocks: writing-mode
No longer depends on: writing-mode
Attached file 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.
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?
Attachment #8610690 - Flags: review?(jwatt)
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.
Attachment #8610690 - Flags: review?(jwatt) → review+
Version: 40 Branch → Trunk
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
Assignee: nobody → jkew
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Assignee: jkew → jfkthame
Depends on: 1340715
The patch in this bug doesn't make sense, as I described in bug 1340715.
Regressions: 1617548
You need to log in before you can comment on or make changes to this bug.