[Cocoa] Attachment dropped from one web view to another is missing its file wrapper

• Component: HTML Editing
• Status: RESOLVED FIXED

To reproduce this bug:

1. Create two editable, attachment-enabled web views
2. Drop a file into the first web view, thus creating an attachment
3. Drag the attachment from the first web view to the other one

Notice that the _WKAttachment instance passed to -_webView:didInsertAttachment:withSource: has a nil info.fileWrapper.

<rdar://problem/45232149>

Seems to also happen with copy and paste!

[Wenson Hsieh]

Created attachment 353411 [details]
Patch

[Wenson Hsieh]

Created attachment 353417 [details]
Try to fix macOS builds

[Wenson Hsieh]

Created attachment 353435 [details]
Try to fix the Windows build

[Tim Horton]

Comment on attachment 353435 [details]
Try to fix the Windows build

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

> Source/WebCore/html/HTMLAttachmentElement.cpp:91
> +    return URLParser(makeString("applewebdata://attachment/"_s, identifier)).result();

It feels weird/scary to build a URL by concatenating strings. But it seems like we don't have a mutable URL? What happens if identifier (which comes from where?) has non-path-safe characters?

[Wenson Hsieh]

Comment on attachment 353435 [details]
Try to fix the Windows build

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

>> Source/WebCore/html/HTMLAttachmentElement.cpp:91
>> +    return URLParser(makeString("applewebdata://attachment/"_s, identifier)).result();
> 
> It feels weird/scary to build a URL by concatenating strings. But it seems like we don't have a mutable URL? What happens if identifier (which comes from where?) has non-path-safe characters?

Good point — the identifier _normally_ comes from within WebKit (createCanonicalUUIDString()) and it's only exposed as a readonly attribute to internal clients. That being said, we do have a mechanism for temporarily saving the identifier as an attribute on the attachment element (see "webkitattachmentid"). Using this, it should be possible to influence the identifier of a pasted/dropped attachment element by writing a webarchive to the pasteboard with an attachment element that contains this attribute...

I've changed this to use URL::setPath() to set the path of the URL, and verified that non-path-safe characters (e.g. space) are URL-encoded.

[Wenson Hsieh]

Created attachment 353456 [details]
Try to fix the Windows build (2)

[Wenson Hsieh]

Created attachment 353458 [details]
Try to fix the Windows build (3)

[Wenson Hsieh]

Created attachment 353459 [details]
Try to fix the Windows build (4)

[Wenson Hsieh]

Created attachment 353460 [details]
Try to fix the Windows build (4.1)

[Wenson Hsieh]

Created attachment 353461 [details]
Try to fix the Windows build (5)

[WebKit Commit Bot]

Comment on attachment 353461 [details]
Try to fix the Windows build (5)

Clearing flags on attachment: 353461

Committed r237624: <https://trac.webkit.org/changeset/237624>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

*** Bug 188904 has been marked as a duplicate of this bug. ***