Bug 188490 – [macOS 10.15] Image dragged from Safari does not appear in Notes

• Component: HTML Editing
• Status: RESOLVED FIXED

[Wenson Hsieh]

<rdar://problem/42830265>

[Wenson Hsieh]

Created attachment 346990 [details]
Patch

[Wenson Hsieh]

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.

[Wenson Hsieh]

Created attachment 347062 [details]
Drop the image into the area below

Test case

[EWS Watchlist]

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

[EWS Watchlist]

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

[Wenson Hsieh]

<rdar://problem/39462717>

[Wenson Hsieh]

Created attachment 375417 [details]
Patch

[Wenson Hsieh]

Comment on attachment 375417 [details]
Patch

Thanks for the review!

[Wenson Hsieh]

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.

[WebKit Commit Bot]

Comment on attachment 375417 [details]
Patch

Clearing flags on attachment: 375417

Committed r248166: <https://trac.webkit.org/changeset/248166>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.