Bug 5789 - iframe with height in % within table is not rendered.
Summary: iframe with height in % within table is not rendered.
Status: RESOLVED DUPLICATE of bug 15359
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Major
Assignee: Nobody
URL: http://www.akafoe.de
Keywords: HasReduction, InRadar
: 5592 10643 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-11-21 02:03 PST by Roberto Avanzi
Modified: 2010-06-11 17:22 PDT (History)
8 users (show)

See Also:


Attachments
file needed for testcase (114 bytes, text/html)
2005-11-22 13:58 PST, Joost de Valk (AlthA)
no flags Details
Testcase (315 bytes, text/html)
2005-11-22 13:59 PST, Joost de Valk (AlthA)
no flags Details
image testcase (297 bytes, text/html)
2006-03-21 15:06 PST, Sam Weinig
no flags Details
patch (2.59 KB, patch)
2006-03-27 15:15 PST, Sam Weinig
hyatt: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Roberto Avanzi 2005-11-21 02:03:43 PST
The webpage http://www.akafoe.de (anyway horribly built) is not rendered. In particular, I cannot see 
some "frames" that appear with Opera (9.0pr1), but "cut off" in the lower part, and that render fine with 
Firefox (1.5) or Camino (1.0b1).  Most likely the cause is a duplicate bug, but cannot track it down.
Comment 1 Joost de Valk (AlthA) 2005-11-22 13:57:23 PST
Confirmed, reduced and renamed, uploading testcase in a sec. 
Comment 2 Joost de Valk (AlthA) 2005-11-22 13:58:28 PST
Created attachment 4770 [details]
file needed for testcase

This file is needed for the testcase i'll upload in a sec.
Comment 3 Joost de Valk (AlthA) 2005-11-22 13:59:53 PST
Created attachment 4771 [details]
Testcase

this is a minimal testcase for the bug, using the previously uploaded file.
Comment 4 Eric Seidel (no email) 2005-12-27 16:22:19 PST
I swear I saw a bug just like this earlier going through bugs, but I can't find it now.
Comment 5 Joost de Valk (AlthA) 2005-12-27 23:57:32 PST
*** Bug 5592 has been marked as a duplicate of this bug. ***
Comment 6 Joost de Valk (AlthA) 2005-12-27 23:59:34 PST
Upping the priority on this one, since even 100% height iframe don't get rendered and this bug has been 
reported on more pages, will enhance the testcase a bit in a second. 
Comment 7 Alice Liu 2006-01-10 14:03:49 PST
<rdar://problem/3184552>
Comment 8 Sam Weinig 2006-03-21 15:02:44 PST
This is actually a bug for all replaced elements (subclasses of RenderReplaced in the the code) in webcore, including images.  It seems to stem from the fact that we do not correctly honor the scenerio when a percentage height of an object depends on its containing blocks height, which in turn can only be calculated using the content height of the inner object.  My reading of the correct behavior is to have the percentage height compute to the value of 'auto' and then perceed as normal (in the case of an image where there is an intrinsic width and height, by using the specified width in conjuction with the intrinsic ratio (h/w) to calculate the height, or with an iframe, by setting the height to 150px), as can be seen in the section 10.5 of the CSS 2.1 spec. (http://www.w3.org/TR/CSS21/visudet.html#the-height-property).  

Sidenote:  Firefoxes behavior here does not conform with what I am interpreting the spec says, but instead uses the percentage value given to height to give a computed value that is that percent of the size that it should be.  I don't know what to make of that.
Comment 9 Sam Weinig 2006-03-21 15:06:02 PST
Created attachment 7222 [details]
image testcase

test case with image instread of iframe
Comment 10 Sam Weinig 2006-03-21 15:11:33 PST
Another thing I should mention is that since this only occurs when the height of the containing block is base on the height of its contents, setting a height for the <td> cell in which the image or iframe resides, causes the problem to disappear. 
Comment 11 Dave Hyatt 2006-03-22 15:54:05 PST
This should not be p1.  Putting in p2.
Comment 12 Dave Hyatt 2006-03-22 15:54:43 PST
P1 = crashers/regressions. :)
Comment 13 Sam Weinig 2006-03-27 15:15:14 PST
Created attachment 7342 [details]
patch

This patch matches the horizontal behavior and in addition to the new test case in the patch, changes the following test cases:

fast/replaced/width100percent.html
tables/mozilla/bugs/bug137388-2.html
tables/mozilla_expected_failures/bugs/bug137388-1.html

The last two, however, still do not display correctly as they are missing the requisite files.
Comment 14 Dave Hyatt 2006-04-17 17:47:53 PDT
Comment on attachment 7342 [details]
patch

Seems like this will do the wrong thing when a height of 0px is explicitly specified.

<div style="height:0px"><img style="height:50%"></div>
Comment 15 Sam Weinig 2006-04-21 13:45:49 PDT
(In reply to comment #14)

Hyatt,
Your absolutly correct that a container height of 0px would result in the incorrect behavior.  This was done to match the horizontal behavior which is also wrong.  Just test the horizontal corollary to your example,

<div style="width: 0px"><img style="height:50%"></div>

and notice that the image is not 0 width.

A better/correct behavior would be to check if the containing block has a non-auto height instead of a positive height.  Do you think that width should be changed as well?
Comment 16 Alexey Proskuryakov 2006-11-02 10:58:15 PST
*** Bug 10643 has been marked as a duplicate of this bug. ***
Comment 17 David Kilzer (:ddkilzer) 2008-02-22 16:47:05 PST
Most test cases in this bug were fixed by Bug 15359.

Sam's test case in Comment #15 doesn't render zero-width, but it does render the same in WebKit r30458 as in Opera 9.2x, Firefox 2 and Firefox 3.

I suggest closing this as RESOLVED/FIXED (or marking a duplicate of Bug 15359).

Comment 18 Alexey Proskuryakov 2010-06-11 17:22:05 PDT
As David said. Please file separate bugs for any remaining issues, if any.

*** This bug has been marked as a duplicate of bug 15359 ***