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

Status: RESOLVED WORKSFORME

(Core :: SVG, defect, P3)

Description

[Jesse Ruderman]

Attachment: testcase

<svg style="display: table-row;"> is extremely tall (about nscoord_MAX tall).

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

Comment 2

[Jonathan Watt [:jwatt]]

Why is this blocking? What is bug 331889?

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Jonathan Watt [:jwatt]]

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?

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase w/ img -- NOT tall

(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. :))

Comment 6

[Boris Zbarsky [:bzbarsky]]

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.

Comment 7

[Robert Longson [:longsonr]]

Seems OK now.