Open Bug 253363 Opened 21 years ago Updated 2 years ago

IFRAME with 100% height has a fixed minimum size inside TABLE cell with relative height

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

defect

Tracking

()

People

(Reporter: syntheticrage, Unassigned)

References

()

Details

(Keywords: testcase, Whiteboard: DUPEME)

Attachments

(4 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040726 Firefox/0.9.1+ (MOOX-AV) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040726 Firefox/0.9.1+ (MOOX-AV) To show this problem in my example URL (HTML 4.01 Strict & validated, but the doctype has no effect on this issue), I've created a page with 100% body height, and two tables, left and right, with 100% height. The table on the right is included only for reference and is not required to exhibit the problem. Each table has two rows: top row has 5% height, bottom row has 95% height. Both rows in the left table contain IFRAMEs with 100% height. Both rows in the right table contain DIVs with 100% height. Even though the two tables are identical, the first row's height is larger on the left table. The IFRAME's height should scale to be equal to 5% of the table height, but it seems to have a "fixed" minimum height of roughly 135px. Also notice, if you resize the browser window, that the bottom IFRAME will resize down until it hits the same minimum height. For comparison, the row heights are correct when this page is viewed in Internet Explorer. Reproducible: Always Steps to Reproduce: 1. view http://www.nulled.com/iframebug.html Actual Results: Left table row height is incorrect (top row height is too large). Right table (included only for reference) row height is correct. Expected Results: Both tables should have identical row heights.
Attached file test-case example
Whiteboard: DUPEME
For whatever it's worth, I've been seeing this bug consistently for several revisions (since Moz 1.4 at least), and it continues to behave in exactly the same way in 1.7.3 and in FF 1.0PR. I've written code to dump the computed style for the iframe when it's refusing to shrink, and the height consistently shows up as 150px. As the window is gradually sized smaller and larger, it's quite clear that the flexing of the iframe works perfectly as long as its size ends up being computed to more than 150px. When the surrounding container flexes to less than 150 px, however, the iframe refuses to shrink accordingly.
Keywords: testcase
iframetest.html creates an iframe from foo.html. Height is 100%, but it fails to display the correct size. Removing the height attribute has the same effect.
I also have seen this bug for a long time. While trying to find a workaround i found that setting the height of the iframe to 50% (as an example) still caused the cell to have a minimum height too large. The point is that it seems that table cells with iframes inside gets a minimum height no matter what the height of the iframe is. I *really* like to see this fixed :-)
I ran into this bug recently, and I found a "hack" to get around this issue. My iframe sized itself correctly when I explicitly set the height of the parent 'td' tag to 100%. Hope this helps.
Attachment #170462 - Attachment mime type: text/html → application/octet-stream
*** Bug 324388 has been marked as a duplicate of this bug. ***
This bug doesn't seem to be related to <td> or <div> or any other tag. The HEIGHT attribute is simply ignored when specified as a percentage. The following code produces different outputs in IE 6 ("almost" the expected result) and in Firefox 2 (height is ignored, no matter under Linux or Windows). -------------------------------------------------------------------- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <!-- $Id Exp $ --> <!--Generated by quanta Plus template - freely use and distribute--> <html> <head> <title>Bug</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="GENERATOR" content="Quanta Plus"> <style type="text/css"> iframe { width : 90%; height : 90%; margin : 10px; border : 0; } </style> </head> <body style="margin-top : 3px;"> <iframe class="external" src="http://www.mozilla.org" scrolling="auto"></iframe> </body> </html> -------------------------------------------------------------------
(In reply to comment #9) > The HEIGHT attribute is simply ignored when specified as a percentage. What you describe is actually correct according to the CSS specification, see bug 243751 (and it has nothing to do with this bug).
Confirming based on testcase.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #10) Bug 243751 is about background image positioning. Here we are talking about iframe sizing. When sizing a iframe, Firefox supports "width : nn%", but does not support "height : nn%". Is it correct according to the CSS specification?
The effect that you complain about has nothing to do with IFRAME in particular, and bug 243751 just discusses similar effects caused by the same rule in the CSS specification: a percentage height is always relative to the size of the containing element (BODY in this case), which has "height: auto" and is therefore sized to fit its contents, i.e. the BODY does _not_ expand to fill the visible window area. Try what Boris Zbarsky has suggested in bug 243751 comment 4: "Put a border on the root to see what it looks like and the rendering should make sense."
(In reply to comment #13) You're right, Elmar. Thank you very much.
I'm having the same bug with Firefox 15; I cannot get an iframe to be smaller than 150px when its height is set as a percentage. My case is similar to the OP's case; I have a table with a td with height=20%, containing an iframe with height=100%. As long as the iframe is present, no resizing will cause the td height to be less than about 150px (give or take margins/padding). If I remove the iframe, the td height is as expected. Setting min-heigh=0 on the iframe does not help. This doesn't seem correct, but I do have to wonder if it is specified somewhere, as webkit behaves the same way.
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: