Summary: | WebKit erroneously add 1px padding in input elements | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> | ||||||||||||||
Component: | Forms | Assignee: | Ryosuke Niwa <rniwa> | ||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||
Severity: | Normal | CC: | adele, ap, darin, dglazkov, d-r, eric, hyatt, jussi.kukkonen, macpherson, menard, naginenis, tkent, webkit.review.bot | ||||||||||||||
Priority: | P2 | ||||||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||
OS: | Unspecified | ||||||||||||||||
Bug Depends on: | 86824, 86825 | ||||||||||||||||
Bug Blocks: | 71323 | ||||||||||||||||
Attachments: |
|
Description
Ryosuke Niwa
2012-05-17 16:01:52 PDT
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 |