SVG in vertical flow computes its size to 0x0

RESOLVED FIXED in Firefox 43

Status

()

RESOLVED FIXED
4 years ago
a year ago

People

(Reporter: kojiishi, Assigned: jfkthame)

Tracking

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

Trunk
mozilla43
css3, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox43 fixed)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

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

Updated

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

Updated

4 years ago
Component: Untriaged → SVG
(Assignee)

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:

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.
Blocks: 145503
No longer depends on: 145503
(Assignee)

Comment 3

4 years ago
Created attachment 8610607 [details]
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.
(Assignee)

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)
(Assignee)

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.

Updated

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

Updated

3 years ago
Version: 40 Branch → Trunk
(Assignee)

Comment 6

3 years ago
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
https://hg.mozilla.org/mozilla-central/rev/4f8b9b50cd93
Assignee: nobody → jkew
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox43: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
(Assignee)

Updated

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