Bug 5789

Confirmed, reduced and renamed, uploading testcase in a sec.

Created attachment 4770 [details] file needed for testcase This file is needed for the testcase i'll upload in a sec.

Created attachment 4771 [details] Testcase this is a minimal testcase for the bug, using the previously uploaded file.

I swear I saw a bug just like this earlier going through bugs, but I can't find it now.

*** Bug 5592 has been marked as a duplicate of this bug. ***

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.

<rdar://problem/3184552>

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.

Created attachment 7222 [details] image testcase test case with image instread of iframe

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.

This should not be p1. Putting in p2.

P1 = crashers/regressions. :)

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

(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?

*** Bug 10643 has been marked as a duplicate of this bug. ***

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

As David said. Please file separate bugs for any remaining issues, if any. *** This bug has been marked as a duplicate of bug 15359 ***