Created attachment 142575 [details] screenshot demonstrating the bug Open the following HTML in WebKit. WebKit renders the caret inside the input element with extra 1px padding whereas the caret inside the textarea doesn't have this 1px padding. <html> <head> <style type="text/css"> .common { font-family: arial,sans-serif; padding-left: 10px; border: 1px solid #D9D9D9; } </style> </head> <body> <input type="text" class="common" value="|"> <br> <textarea class="common">|</textarea> </body> </html> tkent identified this is caused by: http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderTextControlSingleLine.cpp#L481 which was added in http://trac.webkit.org/changeset/13567. http://crbug.com/128086
Created attachment 142576 [details] ie9 (standard mode)
Created attachment 142577 [details] ie9 (quirks mode)
Created attachment 142579 [details] Chrome 18 (for comparison)
It appears that IE doesn't exhibit this behavior anymore.
Just removing the said code doesn't seem to work. fast/forms/input-placeholder-text-indent.html fails with off-by-one error :\
(In reply to comment #5) > Just removing the said code doesn't seem to work. > fast/forms/input-placeholder-text-indent.html fails with off-by-one error :\ We need to remove paddings of ::-webkit-input-placeholder in html.css.
(In reply to comment #6) > (In reply to comment #5) > > Just removing the said code doesn't seem to work. > > fast/forms/input-placeholder-text-indent.html fails with off-by-one error :\ > > We need to remove paddings of ::-webkit-input-placeholder in html.css. That makes sense. I was looking for that in C++ code :( Thanks!
This is a very simple fix but requires a lot of rebaselines (~150 in each platform). Will upload a patch in half an hour.
Created attachment 142634 [details] Fixes the bug
Comment on attachment 142634 [details] Fixes the bug If we need to update a lot of test results, I prefer just marking failures in test_expectations.txt in the patch ;-)
(In reply to comment #10) > (From update of attachment 142634 [details]) > If we need to update a lot of test results, I prefer just marking failures in test_expectations.txt in the patch ;-) Yeah. I probably need to do that instead (or just land and rebaseline them in non-PST time). It's not feasible to land this patch as is :( unless I want to clash the svn server.
Comment on attachment 142634 [details] Fixes the bug Attachment 142634 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12726365 New failing tests: editing/selection/select-across-readonly-input-5.html css3/selectors3/xml/css3-modsel-24.xml editing/selection/drag-select-1.html css3/selectors3/xhtml/css3-modsel-24.xml editing/pasteboard/4806874.html editing/selection/3690719.html css3/selectors3/xhtml/css3-modsel-68.xml editing/selection/4895428-3.html css3/selectors3/html/css3-modsel-24.html editing/input/caret-at-the-edge-of-input.html editing/inserting/before-after-input-element.html editing/selection/select-across-readonly-input-1.html css3/selectors3/xml/css3-modsel-23.xml editing/selection/3690703-2.html editing/selection/4975120.html editing/selection/select-across-readonly-input-2.html editing/selection/select-across-readonly-input-4.html editing/selection/select-across-readonly-input-3.html css3/selectors3/xml/css3-modsel-69.xml editing/pasteboard/drop-text-without-selection.html editing/selection/3690703.html css3/selectors3/html/css3-modsel-23.html css3/selectors3/xml/css3-modsel-68.xml css3/selectors3/html/css3-modsel-69.html css3/selectors3/xhtml/css3-modsel-69.xml editing/pasteboard/input-field-1.html css3/selectors3/xhtml/css3-modsel-23.xml css3/selectors3/html/css3-modsel-68.html
Created attachment 142645 [details] Archive of layout-test-results from ec2-cr-linux-01 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-01 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Oops, I just realized that my previous analysis was wrong. It's not that IE doesn't add 1px padding to input element anymore. It's that IE also adds that 1px padding to textarea :(
This patch was landed in r117556. And rebaselines were done in r117557, r117558, and r117559. But got reverted in r117565, r117566, r117567, and r117570.
Is this the same as bug 71323? > This patch was landed in r117556. Should this bug be RESOLVED/FIXED now?
(In reply to comment #16) > Is this the same as bug 71323? > > > This patch was landed in r117556. > > Should this bug be RESOLVED/FIXED now? No, I reverted it after realizing that my original analysis suffered from off-by-one error.
Okay.. my second analysis was also wrong. The test case for the bug 71323 works fine on IE9: https://bugs.webkit.org/show_bug.cgi?id=71323
I'm sorry, I don't know what's wrong with me. Maybe because it was too late in the evening but it appears that my first analysis was correct (or perhaps that I was fooled by screenshots seen through Screen Share), and my comment #14 was bogus. I'm going to re-land the patch later today while my brain is functioning properly.
Committed in http://trac.webkit.org/changeset/117672. Rebaselines: http://trac.webkit.org/changeset/117673 http://trac.webkit.org/changeset/117674 http://trac.webkit.org/changeset/117676 (philn) http://trac.webkit.org/changeset/117677 http://trac.webkit.org/changeset/117679 http://trac.webkit.org/changeset/117681 (ossy) http://trac.webkit.org/changeset/117682 http://trac.webkit.org/changeset/117686