Create a positioned container, e.g. DIV of say 100 x 100px and place an INPUT inside it. Style the input with { position: absolute; width: auto; left:0; right:0; height: auto; top: 0; bottom:0; border: none; background: none } Now observe on a Mac when the page loads it does not show the Value of the INPUT tag. When you hover over it you can see the blue outline of where the INPUT element should be, but you cannot click inside it to edit the text. But this does work fine on the same version of Chrome for Windows. Adding another style rule: { min-height: 20px } will fix it, but this should not be necessary. In the http://jsfiddle.net/mqJhw/7/ version the min-height workaround is disabled, while in http://jsfiddle.net/mqJhw/6/ it is enabled.
Forgot to mention, that the rendering error exists in both Chrome Canary 21.0.1175.0 and Webkit nightly build r120398, but not in Safari 5.1.7!
Regression range: http://trac.webkit.org/log/trunk/?rev=112129&stop_rev=112101&verbose=on
I confirmed this was a regression by http://trac.webkit.org/changeset/112113 . Julien?
(In reply to comment #3) > I confirmed this was a regression by http://trac.webkit.org/changeset/112113 . > Julien? It looks like the issue was already present but uncovered by the changeset. The core of the issue is that we override the style's height in RenderTextControlSingleLine::layout. In this case, because of the input's containing block is a cell, it hasn't been laid out yet and we improperly constrain the <input>'s inner blocks to have a 0 height. The second layout unfortunately re-uses the previous (wrong) value and over-constrain. I fear that to fix the regression, we need to remove the height-override hacks (which would be a good change but non-trivial). A system akin to cell's intrinsic padding should give us what we want.
Created attachment 151526 [details] Reduction
Created attachment 151544 [details] Proposed fix, reset overriden height before laying out.
Comment on attachment 151544 [details] Proposed fix, reset overriden height before laying out. Clearing flags on attachment: 151544 Committed r122290: <http://trac.webkit.org/changeset/122290>
All reviewed patches have been landed. Closing bug.
On EFL and GTK ports, the test is failing because we cannot see the date in the second <input>.
(In reply to comment #9) > On EFL and GTK ports, the test is failing because we cannot see the date in the second <input>. Same for Qt port.
(In reply to comment #10) > (In reply to comment #9) > > On EFL and GTK ports, the test is failing because we cannot see the date in the second <input>. > > Same for Qt port. The second input is of type 'date'[1]. I believe for the test to properly function, the ENABLE_INPUT_TYPE_DATE feature should be enabled. Most ports don't enable it, though, so that's probably why the test fails: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&tests=fast%2Fforms%2Finput-in-table-cell-no-value.html [1] - http://trac.webkit.org/browser/trunk/LayoutTests/fast/forms/input-in-table-cell-no-value.html?rev=122290#L29
(In reply to comment #11) > The second input is of type 'date'[1]. I believe for the test to properly function, the ENABLE_INPUT_TYPE_DATE feature should be enabled. Most ports don't enable it, though, so that's probably why the test fails: > http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&tests=fast%2Fforms%2Finput-in-table-cell-no-value.html I don't this so. If a port has no INPUT_TYPE_DATE, <input type=date> should work as <input type=text>, and the test HTML and the reference HTML produce the identical image. Probably repainting issue?
(In reply to comment #12) > > Probably repainting issue? I'm not sure that's the issue. When running the test and expected HTML manually the difference still occurs. Expected HTML renders the date in text but the test HTML doesn't.
(In reply to comment #13) > (In reply to comment #12) > > > > Probably repainting issue? > > I'm not sure that's the issue. When running the test and expected HTML manually the difference still occurs. Expected HTML renders the date in text but the test HTML doesn't. I see. type=date and type=text have some differences. Probably the patch fixed type=number and type=date case, but didn't fix type=text case. The patch itself isn't harmful. I think we had better skip the test on ports without INPUT_TYPE_DATE, and fix the type=text case later.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > > > > Probably repainting issue? > > > > I'm not sure that's the issue. When running the test and expected HTML manually the difference still occurs. Expected HTML renders the date in text but the test HTML doesn't. > > I see. > type=date and type=text have some differences. Probably the patch fixed type=number and type=date case, but didn't fix type=text case. > The patch itself isn't harmful. I think we had better skip the test on ports without INPUT_TYPE_DATE, and fix the type=text case later. Looks like the test was disabled on non chromium platforms, sorry for the breakage. I have filed bug 90987 to track the failure. I hope to look at it after a couple of high-priority bugs on my plate.
<rdar://problem/12685932>