Open Bug 410233 Opened 13 years ago Updated 12 years ago

<svg style="display: table-row;"> is extremely tall


(Core :: SVG, defect, P3)





(Reporter: jruderman, Unassigned)


(Blocks 2 open bugs)


(Keywords: testcase)


(2 files)

Attached file testcase
<svg style="display: table-row;"> is extremely tall (about nscoord_MAX tall).
The problem is that in nsHTMLReflowState::InitConstraints we have |if (NS_CSS_FRAME_TYPE_INTERNAL_TABLE == mFrameType)| testing true.  This is because that test is based entirely on the style-provided display type.  Since we can't actually use replaced elements as internal table elements, the frame tree doesn't particularly match the style in this case.  I would think we'd want to set mFrameType in this case based on the actual frame type...

In any case, the consequence is that we don't ever call ComputeSize() and end up with the default sizing of "unconstrained height" used for table rows.

I would think that an <html:img> would exhibit similar behavior and that this is not SVG-specific...
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Why is this blocking? What is bug 331889?
> Why is this blocking?

It's a regression that's due to us getting confused about the data we're looking at.  Maybe it shouldn't block, but then we should have some indication that everything is safe.  For what it's worth, I do think this might be the case, but someone needs to check and make sure.

> What is bug 331889?

I've cced you on it.
Without someone with the cycles to look at this I'm marking blocking1.9- but wanted1.9+ and wanted1.9.0.x+.

Boris, what would need to happen for you to be satisfied that we're safe?
Flags: wanted1.9.0.x+
Flags: wanted1.9+
Flags: tracking1.9+
Flags: blocking1.9-
OS: Mac OS X → All
Hardware: PC → All
(In reply to comment #1)
> I would think that an <html:img> would exhibit similar behavior and that this
> is not SVG-specific...

FWIW: it actually looks <img> is fine here -- see this attached testcase, which uses 2 <img> tags -- one with src and one without.  Neither triggers a vertical scrollbar (but the initial <svg> testcase does).

I tried this in a plain HTML document, too (rather than XHTML), and I got the same results.

So, maybe this bug is SVG-only after all...?  Or maybe we just have some workaround for <img> that prevents this from happening there.  (Or maybe I'm misunderstanding something. :))
The check in InitConstraints is NS_CSS_FRAME_TYPE_INTERNAL_TABLE == mFrameType.  But for an nsImageFrame we have frame->IsFrameOfType(nsIFrame::eReplaced) so that the type is NS_CSS_FRAME_TYPE_INTERNAL_TABLE | NS_CSS_FRAME_TYPE_REPLACED.

<svg> isn't really nsIFrame::eReplaced.

And yes, it would be good to make InitFrameType use the actual frame's info for the table internal element thing.
You need to log in before you can comment on or make changes to this bug.