Bug 25794 – fast/replaced/table-percent-height-text-controls fails on Windows

• Component: New Bugs
• Status: RESOLVED FIXED

[Adam Roben (:aroben)]

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.

[Adam Roben (:aroben)]

<rdar://problem/6888336>

[Kent Tamura]

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.

[Kent Tamura]

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

[Kent Tamura]

I made a bug for fast/replaced/table-percent-height.html, Bug#31858 .
Sorry for the confusion.

[Brent Fulgham]

This test now passes.