Bug 79385

Summary: REGRESSION (r99369): File input button doesn't highlight when pressed
Product: WebKit Reporter: Daniel Bates <dbates>
Component: FormsAssignee: Daniel Bates <dbates>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, darin, dglazkov, jonlee, mitz, tkent, webkit.review.bot
Priority: P2 Keywords: InRadar, Regression
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
Patch and layout test
webkit.review.bot: commit-queue-
Patch and layout tests tkent: review+, webkit.review.bot: commit-queue-

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-
Patch and layout tests (15.70 KB, patch)
2012-03-10 17:30 PST, Daniel Bates
tkent: review+
webkit.review.bot: commit-queue-
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
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
Note You need to log in before you can comment on or make changes to this bug.