Bug 184237 – [Mac] Prioritize file promises over filenames during drag and drop

• Component: New Bugs
• Status: RESOLVED FIXED

[Andy Estes]

[Mac] Prioritize file promises over filenames during drag and drop

[Andy Estes]

rdar://problem/38278076

[Andy Estes]

Created attachment 336992 [details]
Patch

[Wenson Hsieh]

Comment on attachment 336992 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=336992&action=review

> Source/WebCore/platform/mac/DragDataMac.mm:179
> +        return fileNames();

Nice!

Looks like FileInputType::receiveDroppedFiles uses this when dropping files on a file input. Would this suggest that dropping file promises (without corresponding filenames in the pasteboard) into <input type=file> was broken? Seems like it would be good to add a test case for this if so.

[Andy Estes]

(In reply to Wenson Hsieh from comment #3)
> Comment on attachment 336992 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=336992&action=review
> 
> > Source/WebCore/platform/mac/DragDataMac.mm:179
> > +        return fileNames();
> 
> Nice!
> 
> Looks like FileInputType::receiveDroppedFiles uses this when dropping files
> on a file input. Would this suggest that dropping file promises (without
> corresponding filenames in the pasteboard) into <input type=file> was
> broken? Seems like it would be good to add a test case for this if so.

It wasn't broken. This function would return fileNames() by default if there was no filename type on the pasteboard. We have a test for this, too, which is sadly now failing on Mac EWS :(

I cleared my r? to investigate why.

[Wenson Hsieh]

(In reply to Andy Estes from comment #4)
> (In reply to Wenson Hsieh from comment #3)
> > Comment on attachment 336992 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=336992&action=review
> > 
> > > Source/WebCore/platform/mac/DragDataMac.mm:179
> > > +        return fileNames();
> > 
> > Nice!
> > 
> > Looks like FileInputType::receiveDroppedFiles uses this when dropping files
> > on a file input. Would this suggest that dropping file promises (without
> > corresponding filenames in the pasteboard) into <input type=file> was
> > broken? Seems like it would be good to add a test case for this if so.
> 
> It wasn't broken. This function would return fileNames() by default if there
> was no filename type on the pasteboard. We have a test for this, too, which
> is sadly now failing on Mac EWS :(
> 
> I cleared my r? to investigate why.

I see. Thanks for the explanation!

[EWS Watchlist]

Comment on attachment 336992 [details]
Patch

Attachment 336992 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/7179385

New failing tests:
editing/pasteboard/file-input-files-access-promise.html

[EWS Watchlist]

Created attachment 337003 [details]
Archive of layout-test-results from ews102 for mac-sierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102  Port: mac-sierra  Platform: Mac OS X 10.12.6

[EWS Watchlist]

Comment on attachment 336992 [details]
Patch

Attachment 336992 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/7179632

New failing tests:
editing/pasteboard/file-input-files-access-promise.html

[EWS Watchlist]

Created attachment 337011 [details]
Archive of layout-test-results from ews114 for mac-sierra

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews114  Port: mac-sierra  Platform: Mac OS X 10.12.6

[Andy Estes]

Created attachment 337092 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 337092 [details]
Patch

Clearing flags on attachment: 337092

Committed r230221: <https://trac.webkit.org/changeset/230221>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.