382325 - SVG should fall back to 300px x 150px as per CSS 2.1 section 10.3.2

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Jonathan Watt [:jwatt]]

Attachment: testcase - SVG in absolutely positioned div

Absolutely positioned HTML div elements don't seem to recognize the width and height of content SVG. As a result an absolutely positioned div containing only an svg element will be rendered at zero width and height, and the SVG is never displayed. This used to work before the reflow branch landing.

It's likely that this bug will be fixed when one or all of the bugs in the following list is fixed, but I want to track this particular testcase failure.

https://bugzilla.mozilla.org/buglist.cgi?bug_id=280923,288276,294086,342532,367031

Comment 1

[Jonathan Watt [:jwatt]]

Attachment: testcase - SVG in inline-block div

Comment 2

[Jonathan Watt [:jwatt]]

When verifying any future fix, check that the document repaints correctly when it is loaded in a small window and the window size is increased.

Comment 3

[Jonathan Watt [:jwatt]]

This is fixed by my patch in bug 294086.

Comment 4

[Jonathan Watt [:jwatt]]

Actually no, the two testcases attached to this bug do not render as I originally expected them to after landing the patch for bug 294086. The testcases turn out to be invalid as written since the height of the <svg>'s containing block depends on the <svg>, but the <svg> has an implicit percentage height so depends on its containing block. This cyclic dependency should mean that the height of the SVG falls back to 150px, but the SVG actually doesn't render at all. I need to investigate why.

Comment 5

[Jonathan Watt [:jwatt]]

So in both testcases, both the width and the height of the <div> depend on the child <svg>. The height of the SVG is in fact falling back to 150px, but the width, which should be falling back to 300px, is incorrectly falling back to 0.

Changing the bug Summary to reflect this.

Comment 6

[Jonathan Watt [:jwatt]]

Attachment: SVG in unconstrained table cell

The same problem occurs in HTML tables with unconstrained table cell dimensions.

Comment 7

[Jonathan Watt [:jwatt]]

Attachment: patch

Comment 8

[Robert Longson [:longsonr]]

Could you add something to say where the 300 comes from. i.e. per CSS 2.1 section 10.3.2.  (assuming that's correct).

Comment 9

[Jonathan Watt [:jwatt]]

Good idea. Do you think the following is okay:

    // If we're being called then our containing block's width depends on our
    // width - fall back to 300px as required by CSS 2.1.

Comment 10

[Robert Longson [:longsonr]]

Pointing to the right section of CSS 2.1 would be even better, assuming that's possible.

Comment 11

[Jonathan Watt [:jwatt]]

Uh, I seemed to loose the text over the line break in my paste. I meant:

    // If we're being called then our containing block's width depends on our
    // width - fall back to 300px as required by CSS 2.1 section 10.3.2.

Comment 12

[tor]

Comment on attachment 299203 [details] [diff] [review]
patch

sr=tor with longsonr's comment suggested comment changes.

Comment 13

[Robert Longson [:longsonr]]

(In reply to comment #11)
> Uh, I seemed to loose the text over the line break in my paste. I meant:
> 
>     // If we're being called then our containing block's width depends on our
>     // width - fall back to 300px as required by CSS 2.1 section 10.3.2.
> 

That works for me.

Comment 14

[Jonathan Watt [:jwatt]]

Comment on attachment 299203 [details] [diff] [review]
patch

Requesting approval1.9. Very low risk patch to fix standards compliance issue.

Comment 15

[Jonathan Watt [:jwatt]]

And without this fix the SVG doesn't display at all, so we really do want this.

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 299203 [details] [diff] [review]
patch

a=beltzner for 1.9

Comment 17

[Jonathan Watt [:jwatt]]

Checked in.

Comment 18

[Jonathan Watt [:jwatt]]

Marking in-testsuite- since we decided this is not the right thing to do in bug 382325, and hence the patch here was backed out (in said bug).

Comment 19

[Jonathan Watt [:jwatt]]

Err, bug 414112.