295717 - Iframe does not fill table cell when height=100%

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[Johan Mjönes]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

I tried to create a table with 100% width and height, and add two header rows
and two iframe rows.

The height and width of the iframes are also set to 100% (to fill the table cells).

However, the lower of the two iframes ignores it's set height and always renders
itself to what I believe is the standard height. The table cell is of correct
height, but the iframe does not fill it.

The upper iframe renders correctly.

Reproducible: Always

Steps to Reproduce:
1. Create a table with four rows, with an iframe in row 2 and 4


Actual Results:  
Lower iframe is rendered with default height

Expected Results:  
Lower iframe fills table cell

Comment 1

[Johan Mjönes]

Attachment: Example HTML-file

Comment 2

[Johan Mjönes]

Attachment: Screenshot of bug in action :)

Comment 3

[Uri Bernstein]

See bug 253363, bug 289116.

Comment 4

[Uri Bernstein]

Also see bug 166630, which was duped to bug 10212. There seems to be some
disagreement as to the validity of this. But in any case, it's a duplicate.

Comment 5

[Gunnar Nilsson]

(In reply to comment #4)
I disagree, 10212 is different and should be closed
this one and bug 253363 are NOT solved 

Comment 6

[Gunnar Nilsson]

Attachment: an iframe in a table

Comment 7

[Bernd]

Attachment 185274 [details] is rendered correctly with a current nightly. 
 - the document requires a standards mode rendering.
 - the table cell has auto height.
 - the spec says without any doubt: 
The percentage is calculated with respect to the height of the generated box's
containing block. If the height of the containing block is not specified
explicitly (i.e., it depends on content height), and this element is not
absolutely positioned, the value is interpreted like 'auto'. A percentage height
on the root element is relative to the viewport.

The first testcase is a bug the second one not. To make it more clear:
if one sees a pct height bug one looks first on the rendering mode.
If it is standards mode then the above cited rule applies. If it quirks mode,
one knows that nobody has still provided a consistent description of what has to
happen together with testcases for bug 10212.

The first testcase however seems to be something different.  

Comment 8

[Boris Zbarsky [:bzbarsky]]

Not likely to be a frames issue.  We have existing bugs on tables setting
computed heights weirdly and inconsistently for table cells...

Comment 9

[Elmar Ludwig]

Attachment: minimal testcase (colourized)

Just some random observations made while playing around with a minimal testcase with Firefox 1.5 (final):

I replaced the IFRAMEs with DIVs to make the testcase independend of other files and colourize them. The first DIV gets the full row height, while the second DIV does not, so the behaviour is the same as with the IFRAMES.

In standards mode, both DIVs have the minimal height, which is IMHO correct according to the CSS 2.1 spec, see the quote from comment #7 about percentage height on the DIV being interpreted as "auto".

In quirks more (which this bug is about), the first DIV expands vertically to fill the table row while the second one does not. This is inconsistent and IMHO a bug, independend of the question how the rendering should look like.

Now, if I do either of:

 - delete "height: 100%;" from the first DIV
 - add "height: 100px;" to the TD in the first row
 - completely delete the second row (which does not contain a DIV)

then the second DIV also expands to fill the table row completely.

Comment 10

[Elmar Ludwig]

Attachment: corrected testcase

Sorry, the previous testcase was missing the second table row. Fixed now.

Note to self: Don't edit a testcase while while uploading it... ;-)

Comment 11

[Elmar Ludwig]

Boris Zbarsky wrote:
> We have existing bugs on tables setting computed heights weirdly and
> inconsistently for table cells...

I can't find one right now that seems similar to this one, so I'm confirming this bug for now. There is bug 10212, but that one looks different to me.

Comment 12

[Bernd]

nifty testcase, so that means the third row does not get or issue correctly the 3 reflow (aka special height reflow)

Comment 13

[Bernd]

attachmnet 204786 is now WFM?

Comment 14

[Elmar Ludwig]

(In reply to comment #13)
> attachmnet 204786 is now WFM?

Yes, this works correctly now (both attachment 204786 [details] and attachment 184687 [details]).

fails in 2006-12-07-04 nightly build
works in 2006-12-08-04 nightly build

so this was fixed by the reflow branch landing.

Do we want to add a test for this?