<rdar://problem/42830265>
Created attachment 346990 [details] Patch
I realized on second glance that this patch is not quite right... Suppose we're dragging a file promise within a `WKWebView` (or dragging from one `WKWebView` to another in the same process), and dropping in a custom file upload area that uses DataTransfer API to read files from the pasteboard. Upon drop, we'll call out to the web process to perform the drag operation; the web process then makes a request to the UI process to grab the image on behalf of DataTransfer API, which then causes AppKit to request the data by invoking `-[WKWebView pasteboard:provideDataForType:]`. However, in the meantime, AppKit has already assumed that we've finished from the drag pasteboard after calling `-[WKWebView performDragOperation:]` on the destination-side, and calls `-[WKWebView draggedImage:endedAt:operation:]` on the source. If this patch were to land, we'd end up clearing out our data early, before the destination web view has a chance to ask for it. This can be observed via a simple test case, to be attached shortly. I don't think there's a simple way to fix this; we'd probably have to rewrite our macOS drop handling logic to become like iOS, where we have a heuristic to front-load any data on the pasteboard that the drop destination might access, and then provide a mechanism to answer any questions the web process might have using this subset of the pasteboard. iOS is only implemented this way because, unlike macOS, the data of a drag session backed by NSItemProviders is accessible *only* within the scope of the call to perform a drop. On the other hand, due to the persistent nature of NSPasteboard on macOS, we have the ability to just lazily fetch data as needed. I guess a cheap (non-?)solution is to just keep the drag data around on WebViewImpl until the next drag happens...but this is far less than ideal.
Created attachment 347062 [details] Drop the image into the area below Test case
Comment on attachment 346990 [details] Patch Attachment 346990 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/8884868 New failing tests: http/tests/security/contentSecurityPolicy/userAgentShadowDOM/allow-video.html
Created attachment 347315 [details] Archive of layout-test-results from ews205 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews205 Port: win-future Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit
<rdar://problem/39462717>
Created attachment 375417 [details] Patch
Comment on attachment 375417 [details] Patch Thanks for the review!
The api-mac bot encountered these failures: > Test suite failed > Timeout > TestWebKitAPI.Challenge.BasicProposedCredential > TestWebKitAPI.WKWebsiteDataStore.FetchPersistentCredentials > TestWebKitAPI.Challenge.SecIdentity …which don’t seem related to this change.
Comment on attachment 375417 [details] Patch Clearing flags on attachment: 375417 Committed r248166: <https://trac.webkit.org/changeset/248166>
All reviewed patches have been landed. Closing bug.