WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 64692
File upload control - filename text not aligned with button text
https://bugs.webkit.org/show_bug.cgi?id=64692
Summary
File upload control - filename text not aligned with button text
dubroy
Reported
2011-07-18 06:41:42 PDT
Created
attachment 101155
[details]
Don't include border, padding, and margin when calculating text baseline Observed in the following products: - Chromium 14.0.826.0 on Ubuntu 10.04 - WebKit 535.1 (trunk@91174) - Epiphany 2.30.2, Ubuntu 10.04 In file upload controls (e.g. on
http://validator.w3.org/#validate_by_upload
), the filename text is not aligned with the button text -- it's several pixels too low (see attached screenshot). I've attached a patch which seem to fix the problem. It looks like the code was accounting for the button's border, padding, & margin when the absoluteBoundingBoxRect already accounts for that.
Attachments
Don't include border, padding, and margin when calculating text baseline
(812 bytes, patch)
2011-07-18 06:41 PDT
,
dubroy
no flags
Details
Formatted Diff
Diff
Fix
(1.66 KB, patch)
2011-07-20 04:51 PDT
,
dubroy
no flags
Details
Formatted Diff
Diff
Correct style problems.
(1.74 KB, patch)
2011-07-20 05:04 PDT
,
dubroy
webkit.review.bot
: commit-queue-
Details
Formatted Diff
Diff
Current file upload control with misaligned text.
(1.85 KB, image/png)
2011-07-21 07:51 PDT
,
dubroy
no flags
Details
New file upload control with aligned text.
(1.73 KB, image/png)
2011-07-21 07:51 PDT
,
dubroy
no flags
Details
Fix with new baselines for chromium-linux, and exceptions for chromium-win and gtk.
(202.62 KB, patch)
2011-07-26 08:15 PDT
,
dubroy
no flags
Details
Formatted Diff
Diff
Fix style (add missing expectations).
(202.72 KB, patch)
2011-07-26 08:25 PDT
,
dubroy
no flags
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
2011-07-18 10:24:38 PDT
Please follow the guidelines for contributing code <
http://www.webkit.org/coding/contributing.html
> to get the fix landed.
Kent Tamura
Comment 2
2011-07-18 19:22:11 PDT
http://code.google.com/p/chromium/issues/detail?id=89591
dubroy
Comment 3
2011-07-20 04:51:50 PDT
Created
attachment 101451
[details]
Fix A properly formatted WebKit patch this time.
WebKit Review Bot
Comment 4
2011-07-20 04:53:39 PDT
Attachment 101451
[details]
did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1 Source/WebCore/ChangeLog:3: Line contains tab character. [whitespace/tab] [5] Source/WebCore/ChangeLog:4: Line contains tab character. [whitespace/tab] [5] Source/WebCore/ChangeLog:5: Line contains tab character. [whitespace/tab] [5] Source/WebCore/ChangeLog:1: ChangeLog entry has no bug number [changelog/bugnumber] [5] Total errors found: 4 in 1 files If any of these errors are false positives, please file a bug against check-webkit-style.
dubroy
Comment 5
2011-07-20 05:04:33 PDT
Created
attachment 101452
[details]
Correct style problems.
WebKit Review Bot
Comment 6
2011-07-20 05:29:54 PDT
Comment on
attachment 101452
[details]
Correct style problems.
Attachment 101452
[details]
did not pass chromium-ews (chromium-xvfb): Output:
http://queues.webkit.org/results/9193236
New failing tests: fast/forms/input-file-re-render.html fast/forms/form-element-geometry.html fast/forms/file-input-direction.html fast/forms/input-appearance-height.html fast/forms/input-value.html fast/forms/box-shadow-override.html fast/forms/file-input-disabled.html
dubroy
Comment 7
2011-07-20 06:27:48 PDT
These failures are all expected, since this patch changes the layout of file upload controls. I think we'll want to rebaseline the tests for this patch. I can include the new images for chromium-linux in my patch, if that's the right thing to do.
dubroy
Comment 8
2011-07-21 07:51:05 PDT
Created
attachment 101589
[details]
Current file upload control with misaligned text.
dubroy
Comment 9
2011-07-21 07:51:37 PDT
Created
attachment 101590
[details]
New file upload control with aligned text.
dubroy
Comment 10
2011-07-21 08:12:41 PDT
I've visually confirmed that all of tests failures in fast/forms are due to the changed text alignment, and they should all be rebaselined. Let me know if there's anything else I need to do to help land this patch.
Dimitri Glazkov (Google)
Comment 11
2011-07-21 09:14:18 PDT
Comment on
attachment 101452
[details]
Correct style problems. View in context:
https://bugs.webkit.org/attachment.cgi?id=101452&action=review
> Source/WebCore/ChangeLog:7 > + already accounted for by RenderButton::absoluteBoundingBoxRect().
Are you sure about this? Where?
http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderObject.cpp&l=1085
dubroy
Comment 12
2011-07-21 09:42:52 PDT
Comment on
attachment 101452
[details]
Correct style problems. View in context:
https://bugs.webkit.org/attachment.cgi?id=101452&action=review
>> Source/WebCore/ChangeLog:7 >> + already accounted for by RenderButton::absoluteBoundingBoxRect(). > > Are you sure about this? Where?
http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderObject.cpp&l=1085
You're right, that's wrong. I think the margin, border, and padding is accounted for by RenderBox::baselinePosition() (
http://codesearch.google.com/#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderBox.cpp&exact_package=chromium&q=baselinePosition&type=cs&l=3295
). I verified this experimentally, but I can double-check the flow with a debugger. I'll fix the comment in a new patch.
dubroy
Comment 13
2011-07-21 09:46:26 PDT
Comment on
attachment 101452
[details]
Correct style problems. View in context:
https://bugs.webkit.org/attachment.cgi?id=101452&action=review
>>> Source/WebCore/ChangeLog:7 >>> + already accounted for by RenderButton::absoluteBoundingBoxRect(). >> >> Are you sure about this? Where?
http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderObject.cpp&l=1085
> > You're right, that's wrong. I think the margin, border, and padding is accounted for by RenderBox::baselinePosition() (
http://codesearch.google.com/#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderBox.cpp&exact_package=chromium&q=baselinePosition&type=cs&l=3295
). > > I verified this experimentally, but I can double-check the flow with a debugger. > > I'll fix the comment in a new patch.
Whoops, that should be RenderBlock::baselinePosition:
http://codesearch.google.com/#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderBlock.cpp&exact_package=chromium&q=baselinePosition&type=cs&l=5174
Dimitri Glazkov (Google)
Comment 14
2011-07-21 10:00:51 PDT
(In reply to
comment #13
)
> (From update of
attachment 101452
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=101452&action=review
> > >>> Source/WebCore/ChangeLog:7 > >>> + already accounted for by RenderButton::absoluteBoundingBoxRect(). > >> > >> Are you sure about this? Where?
http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderObject.cpp&l=1085
> > > > You're right, that's wrong. I think the margin, border, and padding is accounted for by RenderBox::baselinePosition() (
http://codesearch.google.com/#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderBox.cpp&exact_package=chromium&q=baselinePosition&type=cs&l=3295
). > > > > I verified this experimentally, but I can double-check the flow with a debugger. > > > > I'll fix the comment in a new patch. > > Whoops, that should be RenderBlock::baselinePosition:
http://codesearch.google.com/#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderBlock.cpp&exact_package=chromium&q=baselinePosition&type=cs&l=5174
You must be very careful here. Look at this the baseline:
http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium-mac-leopard/fast/forms/input-file-re-render-expected.png
It's aligned perfectly. This tells me that baselinePosition calculates a different value on Mac. Why? I don't know, but it's worth finding out, since youe change, I am guessing will cause misalignment on Mac.
dubroy
Comment 15
2011-07-21 12:02:26 PDT
I did test on Mac, and it doesn't cause a regression. But you're right -- I should figure out why. After some experimentation, it seems that on Mac, the RenderButton always has 0 padding, margin, and border. Using the following test: <!doctype html> <title></title> <input type="file" style="border: 2px solid black;"></input> The render tree on Mac is the following: layer at (0,0) size 800x600 RenderView at (0,0) size 800x600 layer at (0,0) size 800x42 RenderBlock {HTML} at (0,0) size 800x42 RenderBody {BODY} at (8,8) size 784x26 RenderFileUploadControl {INPUT} at (2,2) size 241x22 "no file selected" [border: (2px solid #000000)] RenderButton {INPUT} at (2,2) size 78x18 [bgcolor=#C0C0C0] RenderBlock (anonymous) at (8,2) size 62x13 RenderText at (0,0) size 62x13 text run at (0,0) width 62: "Choose File" RenderText {#text} at (0,0) size 0x0 #EOF And on Chromium Linux: layer at (0,0) size 800x600 RenderView at (0,0) size 800x600 layer at (0,0) size 800x46 RenderBlock {HTML} at (0,0) size 800x46 RenderBody {BODY} at (8,8) size 784x30 RenderFileUploadControl {INPUT} at (2,2) size 242x26 "No file chosen" [border: (2px solid #000000)] RenderButton {INPUT} at (2,2) size 85x22 [bgcolor=#DDDDDD] [border: (2px outset #DDDDDD)] RenderBlock (anonymous) at (8,3) size 69x16 RenderText at (0,0) size 69x16 text run at (0,0) width 69: "Choose File" RenderText {#text} at (0,0) size 0x0 #EOF Note that on Chromium Linux, the RenderButton inside the FileUploadControl has a 2px border as well. I don't know why that's the case though.
Dimitri Glazkov (Google)
Comment 16
2011-07-21 12:22:08 PDT
(In reply to
comment #15
)
> > Note that on Chromium Linux, the RenderButton inside the FileUploadControl has a 2px border as well. I don't know why that's the case though.
Thanks for doing this! Now, the only thing we have left is making sure that we don't turn bots red when we land this. Two ways: 1) Add all tests you expect to fail to test_expectations.txt, land, then pull expectations from the build bots and check them in 2) Add expectations ahead of time into the patch. Certainly, #2 is preferred, but both are acceptable.
dubroy
Comment 17
2011-07-21 14:01:56 PDT
Since we are in quite different time zones (I'm in CET), maybe option #2 is best. I can prepare the new baseline results tomorrow morning, and the patch should be ready to land by the time you are back online. BTW, I realized that the border on the RenderButton in this example is always 2px, and it was just a coincidence that I had chosen a 2px border for the upload control style. Even when I set it to 6px, the child RenderButton has the 2px border, so I guess it's just an implementation detail.
dubroy
Comment 18
2011-07-26 08:15:28 PDT
Created
attachment 102006
[details]
Fix with new baselines for chromium-linux, and exceptions for chromium-win and gtk.
WebKit Review Bot
Comment 19
2011-07-26 08:17:08 PDT
Attachment 102006
[details]
did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/plat..." exit_code: 1 Last 3072 characters of output: ions BUGWK64692 : fast/forms/input-value.html ERROR: Line:30 Missing expectations BUGWK64692 : fast/forms/box-shadow-override.html ERROR: Line:31 Missing expectations BUGWK64692 : fast/forms/file-input-disabled.html LayoutTests/platform/gtk/test_expectations.txt:25: Missing expectations BUGWK64692 : fast/forms/input-file-re-render.html [test/expectations] [5] LayoutTests/platform/gtk/test_expectations.txt:26: Missing expectations BUGWK64692 : fast/forms/form-element-geometry.html [test/expectations] [5] LayoutTests/platform/gtk/test_expectations.txt:27: Missing expectations BUGWK64692 : fast/forms/file-input-direction.html [test/expectations] [5] LayoutTests/platform/gtk/test_expectations.txt:28: Missing expectations BUGWK64692 : fast/forms/input-appearance-height.html [test/expectations] [5] LayoutTests/platform/gtk/test_expectations.txt:29: Missing expectations BUGWK64692 : fast/forms/input-value.html [test/expectations] [5] LayoutTests/platform/gtk/test_expectations.txt:30: Missing expectations BUGWK64692 : fast/forms/box-shadow-override.html [test/expectations] [5] LayoutTests/platform/gtk/test_expectations.txt:31: Missing expectations BUGWK64692 : fast/forms/file-input-disabled.html [test/expectations] [5] ERROR: FAILURES FOR <lucid, x86_64, release, cpu> ERROR: Line:3920 Missing expectations BUGWK64692 WIN : fast/forms/input-file-re-render.html ERROR: Line:3921 Missing expectations BUGWK64692 WIN : fast/forms/form-element-geometry.html ERROR: Line:3922 Missing expectations BUGWK64692 WIN : fast/forms/file-input-direction.html ERROR: Line:3923 Missing expectations BUGWK64692 WIN : fast/forms/input-appearance-height.html ERROR: Line:3924 Missing expectations BUGWK64692 WIN : fast/forms/input-value.html ERROR: Line:3925 Missing expectations BUGWK64692 WIN : fast/forms/box-shadow-override.html ERROR: Line:3926 Missing expectations BUGWK64692 WIN : fast/forms/file-input-disabled.html LayoutTests/platform/chromium/test_expectations.txt:3920: Missing expectations BUGWK64692 WIN : fast/forms/input-file-re-render.html [test/expectations] [5] LayoutTests/platform/chromium/test_expectations.txt:3921: Missing expectations BUGWK64692 WIN : fast/forms/form-element-geometry.html [test/expectations] [5] LayoutTests/platform/chromium/test_expectations.txt:3922: Missing expectations BUGWK64692 WIN : fast/forms/file-input-direction.html [test/expectations] [5] LayoutTests/platform/chromium/test_expectations.txt:3923: Missing expectations BUGWK64692 WIN : fast/forms/input-appearance-height.html [test/expectations] [5] LayoutTests/platform/chromium/test_expectations.txt:3924: Missing expectations BUGWK64692 WIN : fast/forms/input-value.html [test/expectations] [5] LayoutTests/platform/chromium/test_expectations.txt:3925: Missing expectations BUGWK64692 WIN : fast/forms/box-shadow-override.html [test/expectations] [5] LayoutTests/platform/chromium/test_expectations.txt:3926: Missing expectations BUGWK64692 WIN : fast/forms/file-input-disabled.html [test/expectations] [5] Total errors found: 14 in 4 files If any of these errors are false positives, please file a bug against check-webkit-style.
dubroy
Comment 20
2011-07-26 08:25:22 PDT
Created
attachment 102008
[details]
Fix style (add missing expectations). I can't build the GTK port (wrong version of libglib, and I can't upgrade) so I decided to add temporary exceptions for that and the chromium-win port. I've included the new baseline images for chromium-linux though. Hope that's ok. As soon as this lands, I'll upload a patch with the new baseline images for GTK and chromium-win.
Dimitri Glazkov (Google)
Comment 21
2011-07-26 08:52:11 PDT
(In reply to
comment #20
)
> Created an attachment (id=102008) [details] > Fix style (add missing expectations). > > I can't build the GTK port (wrong version of libglib, and I can't upgrade) so I decided to add temporary exceptions for that and the chromium-win port. I've included the new baseline images for chromium-linux though. Hope that's ok. > > As soon as this lands, I'll upload a patch with the new baseline images for GTK and chromium-win.
Did you mean to not mark it for review?
dubroy
Comment 22
2011-07-26 09:09:13 PDT
No, I didn't mean to. This being my first WebKit submission, I didn't actually realize I needed to do that...and it took me a few minutes to figure out how :-)
Dimitri Glazkov (Google)
Comment 23
2011-07-26 09:10:38 PDT
Comment on
attachment 102008
[details]
Fix style (add missing expectations). Energize!
WebKit Review Bot
Comment 24
2011-07-26 10:09:13 PDT
Comment on
attachment 102008
[details]
Fix style (add missing expectations). Clearing flags on attachment: 102008 Committed
r91759
: <
http://trac.webkit.org/changeset/91759
>
WebKit Review Bot
Comment 25
2011-07-26 10:09:19 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug