SVG in vertical flow computes its size to 0x0

RESOLVED FIXED in Firefox 43



4 years ago
a year ago


(Reporter: kojiishi, Assigned: jfkthame)


(Depends on: 1 bug, Blocks: 1 bug, {css3, testcase})

css3, testcase
Dependency tree / graph

Firefox Tracking Flags

(firefox43 fixed)




(3 attachments)



4 years ago
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...


4 years ago
Component: Untriaged → Untriaged
Depends on: 145503
Ever confirmed: true
Keywords: css3, testcase
Product: Firefox → Core
See Also: → bug 319163


4 years ago
Component: Untriaged → SVG

Comment 1

4 years ago
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: 145503
No longer depends on: 145503

Comment 3

4 years ago
Created attachment 8610607 [details]

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

4 years ago
Created attachment 8610690 [details] [diff] [review]
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?
Attachment #8610690 - Flags: review?(jwatt)

Comment 5

4 years ago
Created attachment 8610692 [details]
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.


3 years ago
Attachment #8610690 - Flags: review?(jwatt) → review+


3 years ago
Version: 40 Branch → Trunk

Comment 6

3 years ago
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
Last Resolved: 3 years ago
status-firefox43: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43


3 years ago
Assignee: jkew → jfkthame
You need to log in before you can comment on or make changes to this bug.