Closed
Bug 382325
Opened 18 years ago
Closed 17 years ago
SVG should fall back to 300px x 150px as per CSS 2.1 section 10.3.2
Categories
(Core :: SVG, defect)
Core
SVG
Tracking
()
RESOLVED
FIXED
People
(Reporter: jwatt, Assigned: jwatt)
References
Details
(Keywords: regression, testcase)
Attachments
(4 files)
(deleted),
application/xml
|
Details | |
(deleted),
application/xml
|
Details | |
(deleted),
application/xml
|
Details | |
(deleted),
patch
|
longsonr
:
review+
tor
:
superreview+
beltzner
:
approval1.9+
|
Details | Diff | Splinter Review |
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
Assignee | ||
Updated•18 years ago
|
Attachment #266474 -
Attachment description: testcase → testcase - SVG in absolutely positioned div
Assignee | ||
Comment 1•18 years ago
|
||
Assignee | ||
Updated•18 years ago
|
Summary: Absolutely positioned HTML div doesn't expand around SVG content → Absolutely positioned/inline-block div doesn't expand around child SVG
Assignee | ||
Comment 2•18 years ago
|
||
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.
Assignee | ||
Comment 4•17 years ago
|
||
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.
Assignee: nobody → jwatt
Assignee | ||
Comment 5•17 years ago
|
||
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.
Summary: Absolutely positioned/inline-block div doesn't expand around child SVG → SVG in a positioned/inline-block div should fall back to 300px x 150px
Assignee | ||
Comment 6•17 years ago
|
||
The same problem occurs in HTML tables with unconstrained table cell dimensions.
Assignee | ||
Updated•17 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•17 years ago
|
Summary: SVG in a positioned/inline-block div should fall back to 300px x 150px → SVG in a tables etc should fall back to 300px x 150px
Assignee | ||
Comment 7•17 years ago
|
||
Attachment #299203 -
Flags: superreview?(tor)
Attachment #299203 -
Flags: review?(longsonr)
Comment 8•17 years ago
|
||
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).
Updated•17 years ago
|
Attachment #299203 -
Flags: review?(longsonr) → review+
Assignee | ||
Comment 9•17 years ago
|
||
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•17 years ago
|
||
Pointing to the right section of CSS 2.1 would be even better, assuming that's possible.
Assignee | ||
Comment 11•17 years ago
|
||
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•17 years ago
|
||
Comment on attachment 299203 [details] [diff] [review]
patch
sr=tor with longsonr's comment suggested comment changes.
Attachment #299203 -
Flags: superreview?(tor) → superreview+
Comment 13•17 years ago
|
||
(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.
Assignee | ||
Updated•17 years ago
|
Summary: SVG in a tables etc should fall back to 300px x 150px → SVG should fall back to 300px x 150px as per CSS 2.1 section 10.3.2
Assignee | ||
Comment 14•17 years ago
|
||
Comment on attachment 299203 [details] [diff] [review]
patch
Requesting approval1.9. Very low risk patch to fix standards compliance issue.
Attachment #299203 -
Flags: approval1.9?
Assignee | ||
Comment 15•17 years ago
|
||
And without this fix the SVG doesn't display at all, so we really do want this.
Comment 16•17 years ago
|
||
Comment on attachment 299203 [details] [diff] [review]
patch
a=beltzner for 1.9
Attachment #299203 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Comment 17•17 years ago
|
||
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Flags: in-testsuite?
Assignee | ||
Comment 18•17 years ago
|
||
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).
Flags: in-testsuite? → in-testsuite-
Assignee | ||
Comment 19•17 years ago
|
||
Err, bug 414112.
You need to log in
before you can comment on or make changes to this bug.
Description
•