WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
79385
REGRESSION (
r99369
): File input button doesn't highlight when pressed
https://bugs.webkit.org/show_bug.cgi?id=79385
Summary
REGRESSION (r99369): File input button doesn't highlight when pressed
Daniel Bates
Reported
2012-02-23 11:53:52 PST
Clicking and holding on the file input button doesn't visually highlight the button.
Attachments
Patch and layout test
(15.70 KB, patch)
2012-02-23 11:56 PST
,
Daniel Bates
webkit.review.bot
: commit-queue-
Details
Formatted Diff
Diff
Patch and layout tests
(15.70 KB, patch)
2012-03-10 17:30 PST
,
Daniel Bates
tkent
: review+
webkit.review.bot
: commit-queue-
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Daniel Bates
Comment 1
2012-02-23 11:56:53 PST
Created
attachment 128523
[details]
Patch and layout test
WebKit Review Bot
Comment 2
2012-02-23 13:10:34 PST
Comment on
attachment 128523
[details]
Patch and layout test
Attachment 128523
[details]
did not pass chromium-ews (chromium-xvfb): Output:
http://queues.webkit.org/results/11574412
New failing tests: fast/forms/file/file-input-pressed-state.html
Alexey Proskuryakov
Comment 3
2012-02-24 15:25:49 PST
<
rdar://problem/10907808
>
Daniel Bates
Comment 4
2012-03-10 17:30:14 PST
Created
attachment 131195
[details]
Patch and layout tests Renamed m_lastCanReceiveDroppedFilesState to m_canReceiveDroppedFiles and modified the RenderFileUploadControl constructor to initialize this instance variable with the value of HTMLInputElement::canReceiveDroppedFiles(). On another note, the name "canReceiveDroppedFiles" doesn't sufficiently describe its purpose. HTMLInputElement::canReceiveDroppedFiles() returns true when a person is hovering a dragged file(s) over an <input type="file"> and false otherwise. I can't think of a good name at the moment. Maybe a name that incorporates words/phrases such as "hovering", or "drag entered"? For completeness, the layout test is a pixel test and passes using an Apple Mac WebKit build on my MacBook Pro running 10.7.3. I'll rebaseline the results for the non-Apple Mac ports upon landing this patch.
WebKit Review Bot
Comment 5
2012-03-10 18:27:10 PST
Comment on
attachment 131195
[details]
Patch and layout tests
Attachment 131195
[details]
did not pass chromium-ews (chromium-xvfb): Output:
http://queues.webkit.org/results/11937257
New failing tests: fast/forms/file/file-input-pressed-state.html
Kent Tamura
Comment 6
2012-03-11 19:32:08 PDT
Comment on
attachment 131195
[details]
Patch and layout tests View in context:
https://bugs.webkit.org/attachment.cgi?id=131195&action=review
> LayoutTests/fast/forms/file/file-input-pressed-state.html:7 > +<script> > +if (window.layoutTestController) > + layoutTestController.dumpAsText(true); // Dump pixel test result. > +</script>
Inconsistent indentation. Another <script> block uses 4-space indentation. We had better add a comment that we are not interested in a render tree dump in this test.
Daniel Bates
Comment 7
2012-03-13 13:12:06 PDT
(In reply to
comment #6
)
> > LayoutTests/fast/forms/file/file-input-pressed-state.html:7 > > +<script> > > +if (window.layoutTestController) > > + layoutTestController.dumpAsText(true); // Dump pixel test result. > > +</script> > > Inconsistent indentation. Another <script> block uses 4-space indentation.
Will fix.
> > We had better add a comment that we are not interested in a render tree dump in this test.
Will add HTML comments of the form: <!-- The output of this test is only meaningful as a pixel test result because form controls have a platform-specific look-and-feel. --> <!-- You can run this test either in DRT as a pixel test or by hand. -->
Daniel Bates
Comment 8
2012-03-13 13:16:13 PDT
Committed
r110598
: <
http://trac.webkit.org/changeset/110598
>
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