To reproduce: 1. run-webkit-tests fast/replaced/table-percent-height-text-controls.html The test fails. See <http://build.webkit.org/results/Windows%20Release%20(Tests)/r43709%20(926)/fast/replaced/table-percent-height-text-controls-pretty-diff.html> for a diff of the failure.
<rdar://problem/6888336>
I think we had better modify table-percent-height.html so that it doesn't use concrete pixel numbers. I don't think form controls in non-Mac platforms should have the same dimensions as in Mac. The current tests are like: shouldBe("getComputedStyleForElement(document.getElementById('button-75'), 'height')", "'15px'"); shouldBe("getComputedStyleForElement(document.getElementById('button-100'), 'height')", "'15px'"); This should be changed to: shouldBe("getComputedStyleForElement(document.getElementById('button-75'), "getComputedStyleForElement(document.getElementById('button-100')); And I wonder if some expectations in the test are correct. For input-button, input-reset, input-submit and select, their dimensions in 100% and 75% are same. For input-checkbox, input-file, input-image and input-radio, their heights in 75% are actually 75%. Is this intentional? With Firefox 3.5/Windows and Opera 10.10, dimensions in 100% and 75% are same even for input-checkbox, input-file, input-image and input-radio. IE8's results are broken. Some controls are disappeared and we should not follow this behavior.
(In reply to comment #2) Oh, I added the previous comment to a wrong bug. This bug is for table-percen-height-text-controls.html. My previous comment is for table-percent-height.html.
I made a bug for fast/replaced/table-percent-height.html, Bug#31858 . Sorry for the confusion.
This test now passes.