RESOLVED FIXED 25913
single-file input elements should refuse multi-file drags
https://bugs.webkit.org/show_bug.cgi?id=25913
Summary single-file input elements should refuse multi-file drags
Eric Seidel (no email)
Reported 2009-05-21 00:49:42 PDT
single-file input elements should refuse multi-file drags The current behavior of only accepting the first file is confusing to the user (I would argue). We should match whatever behavior matches the operating system and update the expected results in: LayoutTests/editing/pasteboard/resources/file-input-files-access.js appropriately.
Attachments
Proposed patch (5.53 KB, patch)
2011-12-12 03:10 PST, Rakesh
no flags
Updated patch (5.54 KB, patch)
2011-12-12 23:16 PST, Rakesh
no flags
Updated Patch (5.02 KB, patch)
2011-12-13 12:54 PST, Rakesh
no flags
Eric Seidel (no email)
Comment 1 2009-05-21 04:05:47 PDT
The check which needs to change here is in: bool DragController::canProcessDrag(DragData* dragData) if (dragData->containsFiles() && asFileInput(result.innerNonSharedNode())) return true; probably we should pass the DragData off to the HTMLInputElement and ask it if it can handle the drag. DragData will need to be extended to be able to return the number of files on the clipboard for HTMLInputElement to be able to make this decision.
Rakesh
Comment 2 2011-12-12 03:10:04 PST
Created attachment 118761 [details] Proposed patch Refuse the multiple file drags on single-file input element. Setting the dragSession.operation as DragOperationNone when input element is multiple and number of files are more than 1. I think DragController::canProcessDrag may not be the right place to refuse the drag as if canProcessDrag fails then tryDocumentDrag will fail which may lead to the loading of the file in the browser.
Jon Lee
Comment 3 2011-12-12 08:41:13 PST
Comment on attachment 118761 [details] Proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=118761&action=review > Source/WebCore/page/DragController.cpp:358 > + if (!dragSession.numberOfItemsToBeAccepted || (!m_fileInputElementUnderMouse->multiple() && (numberOfFiles > 1))) Although this is correct, I think it would be better to move this check into the if..else chain starting in line 351 (as penultimate "else if" check). This way the check for setting the operation to None remains simple and comprehensible.
Rakesh
Comment 4 2011-12-12 23:16:09 PST
Created attachment 118960 [details] Updated patch Check moved to if...else chain.
Jon Lee
Comment 5 2011-12-13 09:35:58 PST
Comment on attachment 118960 [details] Updated patch View in context: https://bugs.webkit.org/attachment.cgi?id=118960&action=review > Source/WebCore/page/DragController.cpp:355 > + else if (!m_fileInputElementUnderMouse->multiple() && (numberOfFiles > 1)) The first check is unnecessary. By this point we already know that the file input is not multiple.
Rakesh
Comment 6 2011-12-13 12:54:51 PST
Created attachment 119069 [details] Updated Patch Modified if check.
Eric Seidel (no email)
Comment 7 2011-12-14 12:33:37 PST
Comment on attachment 119069 [details] Updated Patch Seems good to me. I believe Oliver has also worked in drag and drop more recently than I. Did you test against any operating systems?
Rakesh
Comment 8 2011-12-28 06:20:39 PST
(In reply to comment #7) > (From update of attachment 119069 [details]) > Seems good to me. I believe Oliver has also worked in drag and drop more recently than I. > > Did you test against any operating systems? This fix works fine on MAC and GTK. On Windows DragData::numberOfFiles() returns 0, so this fix does not have any effect on Windows.
Eric Seidel (no email)
Comment 9 2012-01-30 16:19:52 PST
Comment on attachment 119069 [details] Updated Patch LGTM.
WebKit Review Bot
Comment 10 2012-01-30 16:35:58 PST
Comment on attachment 119069 [details] Updated Patch Clearing flags on attachment: 119069 Committed r106301: <http://trac.webkit.org/changeset/106301>
WebKit Review Bot
Comment 11 2012-01-30 16:36:04 PST
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.