[Attachment Support] Create attachment elements when dropping files on iOS

https://bugs.webkit.org/show_bug.cgi?id=181192
<rdar://problem/36280945>

Reviewed by Tim Horton.

Source/WebCore:

Implements support for dropping data as attachment elements on iOS. See comments below for more detail.

Tests:  WKAttachmentTests.InsertDroppedRichAndPlainTextFilesAsAttachments
        WKAttachmentTests.InsertDroppedZipArchiveAsAttachment
        WKAttachmentTests.InsertDroppedItemProvidersInOrder

* WebCore.xcodeproj/project.pbxproj:
* editing/WebContentReader.cpp:
(WebCore::WebContentReader::ensureFragment):

Add a new helper to create the WebContentReader's fragment, if it hasn't already been created.

* editing/WebContentReader.h:
* editing/cocoa/WebContentReaderCocoa.mm:
(WebCore::WebContentReader::readFilePaths):

Rename readFilenames to readFilePaths (which better reflects its parameters, which are file paths). Also, move
the implementation of readFilePaths to shared iOS/macOS code in WebContentReaderCocoa, and remove the stub
implementation on iOS.

There's a bit of code here that I kept macOS-only which deals with inserting file paths as plain text in
editable areas, but it's unclear to me why and if WebKit clients currently find this useful, so I left a FIXME
to investigate removing this altogether. Code for handling this plain text insertion of file paths on Mac was
introduced in r67403.

* editing/ios/WebContentReaderIOS.mm:
(WebCore::WebContentReader::readFilenames): Deleted.
* editing/mac/WebContentReaderMac.mm:
(WebCore::WebContentReader::readFilenames): Deleted.
* page/mac/DragControllerMac.mm:
(WebCore::DragController::updateSupportedTypeIdentifiersForDragHandlingMethod const):

Teach DragController to accept all types conforming to "public.item" and "public.content" on iOS, only when
attachment elements are enabled. This allows us to load content from item providers that we otherwise would not
have loaded, since we now have the ability to fall back to attachment element insertion if the type is not have
a default representation using standard web content.

* platform/Pasteboard.h:
* platform/PasteboardItemInfo.h: Added.
(WebCore::PasteboardItemInfo::encode const):
(WebCore::PasteboardItemInfo::decode):

Add PasteboardItemInfo, a struct that describes an item on the pasteboard. Also, implement encoding and decoding
support for PasteboardItemInfo. So far, the item info only describes file information about the pasteboard item,
and flags indicating whether the item prefers attachment or inline presentation.

* platform/PasteboardStrategy.h:

Replace getFilenamesForDataInteraction with informationForItemAtIndex. Instead of returning all of the file
paths associated with any item on the pasteboard, fetch a PasteboardItemInfo at a given item index, which
includes information about the file path as well as some other metadata we'll need when deciding how to read
pasteboard contents as a document fragment.

* platform/PlatformPasteboard.h:
* platform/cocoa/PasteboardCocoa.mm:
(WebCore::Pasteboard::read):
* platform/ios/AbstractPasteboard.h:
* platform/ios/PasteboardIOS.mm:
(WebCore::Pasteboard::read):
(WebCore::Pasteboard::readRespectingUTIFidelities):

Teach the iOS Pasteboard to read web content using attachment elements, if enabled. There are two scenarios in
which we would want to insert an attachment element:
(1) The item provider uses a preferred presentation style of attachment, in which case we bail out of trying to
    handle the drop using the default mechanisms, and simply insert it as an attachment. We need this to deal
    with the case where we drop text or HTML files from the Files app, so that we don't try and insert the
    contents of the text or HTML as inline web content.
(2) The item provider doesn't have a preferred attachment presentation style, but there's nothing WebKit would
    otherwise do with the dropped content, so insert an attachment element as a fallback. Examples where this is
    relevant are dropping a PDF or ZIP archive without attachment presentation style explicitly set.
We first check if we fall into case (1). If so, we can bail early by inserting an attachment; otherwise, we
proceed normally and see if we can read the contents of the drop as web content. If, at the end of default drop
handling, we don't still have a way to represent the dropped content, enter case (2).

(WebCore::Pasteboard::readFilePaths):
(WebCore::Pasteboard::readFilenames): Deleted.

Rename readFilenames to readFilePaths, and reimplement it using informationForItemAtIndex.

* platform/ios/PlatformPasteboardIOS.mm:
(WebCore::pasteboardItemPresentationStyle):
(WebCore::PlatformPasteboard::informationForItemAtIndex):
(WebCore::PlatformPasteboard::filenamesForDataInteraction): Deleted.

Implement informationForItemAtIndex and remove filenamesForDataInteraction. As before, we ask the pasteboard
(i.e. WebItemProviderPasteboard) for information about dropped file URLs. This time, we limit this to a single
file, so we don't end up creating multiple attachment elements for each representation of a single item
provider. See below for -preferredFileUploadURLAtIndex:fileType: for more detail.

* platform/ios/WebItemProviderPasteboard.h:
* platform/ios/WebItemProviderPasteboard.mm:
(-[WebItemProviderLoadResult initWithItemProvider:typesToLoad:]):
(-[WebItemProviderLoadResult canBeRepresentedAsFileUpload]):

Remove this synthesized instance variable and instead just check the item provider's preferredPresentationStyle.

(-[WebItemProviderLoadResult description]):

Add a verbose -description to the load result object. Useful for debugging what was content was loaded from an
item provider on drop.

(-[WebItemProviderPasteboard preferredFileUploadURLAtIndex:fileType:]):

Return the highest fidelity loaded type identifier for a given item.

(-[WebItemProviderPasteboard allDroppedFileURLs]):
(-[WebItemProviderPasteboard typeIdentifiersToLoadForRegisteredTypeIdentfiers:]):

Prefer flat RTFD to RTFD. In the case where attachments are enabled and we're accepting all types of content
using attachment elements as a fallback representation, if the source writes attributed strings to the
pasteboard with com.apple.rtfd at a higher fidelity than com.apple.flat-rtfd, we'll end up loading only
com.apple.rtfd and dropping the text as an attachment element because we cannot convert the dropped content to
markup. Instead, if flat RTFD is present in the item provider, always prefer that over RTFD so that dropping as
regular web content isn't overridden when attachment elements are enabled.

(-[WebItemProviderPasteboard doAfterLoadingProvidedContentIntoFileURLs:synchronousTimeout:]):
(-[WebItemProviderPasteboard droppedFileURLs]): Deleted.
* platform/mac/DragDataMac.mm:
(WebCore::DragData::containsCompatibleContent const):

DragData::containsCompatibleContent should be true when attachment elements are enabled, and there are files we
can drop as attachment elements.

* platform/mac/PasteboardMac.mm:
(WebCore::Pasteboard::read):
(WebCore::Pasteboard::readFilePaths):
(WebCore::Pasteboard::readFilenames): Deleted.

Source/WebKit:

Make some minor adjustments for changes to the pasteboard in WebCore. See WebCore/ChangeLog for more detail.
Teaches WebPasteboardProxy et. al. to plumb PasteboardItemInfo from the UI process to the web process via the
new `InformationForItemAtIndex` codepath.

* UIProcess/Cocoa/WebPasteboardProxyCocoa.mm:
(WebKit::WebPasteboardProxy::informationForItemAtIndex):
(WebKit::WebPasteboardProxy::getFilenamesForDataInteraction): Deleted.
* UIProcess/WebPasteboardProxy.h:
* UIProcess/WebPasteboardProxy.messages.in:
* WebProcess/WebCoreSupport/WebPlatformStrategies.cpp:
(WebKit::WebPlatformStrategies::informationForItemAtIndex):
(WebKit::WebPlatformStrategies::getFilenamesForDataInteraction): Deleted.
* WebProcess/WebCoreSupport/WebPlatformStrategies.h:

Source/WebKitLegacy/mac:

Make some minor adjustments for changes to the pasteboard in WebCore. See WebCore/ChangeLog for more detail.

* WebCoreSupport/WebPlatformStrategies.h:
* WebCoreSupport/WebPlatformStrategies.mm:
(WebPlatformStrategies::informationForItemAtIndex):
(WebPlatformStrategies::getFilenamesForDataInteraction): Deleted.

Tools:

Adds 3 new API tests to exercise different use cases of dropping content as attachment elements when the runtime
switch is enabled. See below for more details.

* TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:
(-[NSItemProvider registerData:type:]):
(platformCopyPNG):
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/ios/DataInteractionTests.mm:

Fix some currently failing iOS drag and drop tests. In this case, there's no reason RTFD should appear in the
source item provider when dragging rich text *without* attachments, so this should have been a check for just
kUTTypeRTF instead.

(TestWebKitAPI::TEST):

Tests a few cases of inserting attachment elements via drop:
1.  We should distinguish between drops containing rich/plain text files from just dropping rich/plain text.
    Instead of inserting the contents as inline web content, this should generate attachment elements.
2.  Test the fallback mechanism for inserting attachment elements. If the preferred presentation style is not
    explicitly set, but there's nothing WebKit would otherwise do with the dropped content, then we should fall
    back to inserting the content as an attachment.
3.  Test that if multiple attachments and inline item providers are present, WebKit will respect the order in
    which they were inserted by the source (as opposed to, for instance, putting all of the attachments in front
    or at the end).

* TestWebKitAPI/cocoa/TestWKWebView.h:
* TestWebKitAPI/cocoa/TestWKWebView.mm:
(-[TestWKWebView objectByEvaluatingJavaScript:]):

Add a helper method to return an object that represents the result of evaluating some given script, and rewrite
-stringByEvaluatingJavaScript to just turn around and call this.

(-[TestWKWebView stringByEvaluatingJavaScript:]):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@226396 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Author: [email protected]

Source/WebCore/ChangeLog

@@ -1,3 +1,139 @@
+2018-01-03  Wenson Hsieh  <[email protected]>
+
+        [Attachment Support] Create attachment elements when dropping files on iOS
+        https://bugs.webkit.org/show_bug.cgi?id=181192
+        <rdar://problem/36280945>
+
+        Reviewed by Tim Horton.
+
+        Implements support for dropping data as attachment elements on iOS. See comments below for more detail.
+
+        Tests:  WKAttachmentTests.InsertDroppedRichAndPlainTextFilesAsAttachments
+                WKAttachmentTests.InsertDroppedZipArchiveAsAttachment
+                WKAttachmentTests.InsertDroppedItemProvidersInOrder
+
+        * WebCore.xcodeproj/project.pbxproj:
+        * editing/WebContentReader.cpp:
+        (WebCore::WebContentReader::ensureFragment):
+
+        Add a new helper to create the WebContentReader's fragment, if it hasn't already been created.
+
+        * editing/WebContentReader.h:
+        * editing/cocoa/WebContentReaderCocoa.mm:
+        (WebCore::WebContentReader::readFilePaths):
+
+        Rename readFilenames to readFilePaths (which better reflects its parameters, which are file paths). Also, move
+        the implementation of readFilePaths to shared iOS/macOS code in WebContentReaderCocoa, and remove the stub
+        implementation on iOS.
+
+        There's a bit of code here that I kept macOS-only which deals with inserting file paths as plain text in
+        editable areas, but it's unclear to me why and if WebKit clients currently find this useful, so I left a FIXME
+        to investigate removing this altogether. Code for handling this plain text insertion of file paths on Mac was
+        introduced in r67403.
+
+        * editing/ios/WebContentReaderIOS.mm:
+        (WebCore::WebContentReader::readFilenames): Deleted.
+        * editing/mac/WebContentReaderMac.mm:
+        (WebCore::WebContentReader::readFilenames): Deleted.
+        * page/mac/DragControllerMac.mm:
+        (WebCore::DragController::updateSupportedTypeIdentifiersForDragHandlingMethod const):
+
+        Teach DragController to accept all types conforming to "public.item" and "public.content" on iOS, only when
+        attachment elements are enabled. This allows us to load content from item providers that we otherwise would not
+        have loaded, since we now have the ability to fall back to attachment element insertion if the type is not have
+        a default representation using standard web content.
+
+        * platform/Pasteboard.h:
+        * platform/PasteboardItemInfo.h: Added.
+        (WebCore::PasteboardItemInfo::encode const):
+        (WebCore::PasteboardItemInfo::decode):
+
+        Add PasteboardItemInfo, a struct that describes an item on the pasteboard. Also, implement encoding and decoding
+        support for PasteboardItemInfo. So far, the item info only describes file information about the pasteboard item,
+        and flags indicating whether the item prefers attachment or inline presentation.
+
+        * platform/PasteboardStrategy.h:
+
+        Replace getFilenamesForDataInteraction with informationForItemAtIndex. Instead of returning all of the file
+        paths associated with any item on the pasteboard, fetch a PasteboardItemInfo at a given item index, which
+        includes information about the file path as well as some other metadata we'll need when deciding how to read
+        pasteboard contents as a document fragment.
+
+        * platform/PlatformPasteboard.h:
+        * platform/cocoa/PasteboardCocoa.mm:
+        (WebCore::Pasteboard::read):
+        * platform/ios/AbstractPasteboard.h:
+        * platform/ios/PasteboardIOS.mm:
+        (WebCore::Pasteboard::read):
+        (WebCore::Pasteboard::readRespectingUTIFidelities):
+
+        Teach the iOS Pasteboard to read web content using attachment elements, if enabled. There are two scenarios in
+        which we would want to insert an attachment element:
+        (1) The item provider uses a preferred presentation style of attachment, in which case we bail out of trying to
+            handle the drop using the default mechanisms, and simply insert it as an attachment. We need this to deal
+            with the case where we drop text or HTML files from the Files app, so that we don't try and insert the
+            contents of the text or HTML as inline web content.
+        (2) The item provider doesn't have a preferred attachment presentation style, but there's nothing WebKit would
+            otherwise do with the dropped content, so insert an attachment element as a fallback. Examples where this is
+            relevant are dropping a PDF or ZIP archive without attachment presentation style explicitly set.
+        We first check if we fall into case (1). If so, we can bail early by inserting an attachment; otherwise, we
+        proceed normally and see if we can read the contents of the drop as web content. If, at the end of default drop
+        handling, we don't still have a way to represent the dropped content, enter case (2).
+
+        (WebCore::Pasteboard::readFilePaths):
+        (WebCore::Pasteboard::readFilenames): Deleted.
+
+        Rename readFilenames to readFilePaths, and reimplement it using informationForItemAtIndex.
+
+        * platform/ios/PlatformPasteboardIOS.mm:
+        (WebCore::pasteboardItemPresentationStyle):
+        (WebCore::PlatformPasteboard::informationForItemAtIndex):
+        (WebCore::PlatformPasteboard::filenamesForDataInteraction): Deleted.
+
+        Implement informationForItemAtIndex and remove filenamesForDataInteraction. As before, we ask the pasteboard
+        (i.e. WebItemProviderPasteboard) for information about dropped file URLs. This time, we limit this to a single
+        file, so we don't end up creating multiple attachment elements for each representation of a single item
+        provider. See below for -preferredFileUploadURLAtIndex:fileType: for more detail.
+
+        * platform/ios/WebItemProviderPasteboard.h:
+        * platform/ios/WebItemProviderPasteboard.mm:
+        (-[WebItemProviderLoadResult initWithItemProvider:typesToLoad:]):
+        (-[WebItemProviderLoadResult canBeRepresentedAsFileUpload]):
+
+        Remove this synthesized instance variable and instead just check the item provider's preferredPresentationStyle.
+
+        (-[WebItemProviderLoadResult description]):
+
+        Add a verbose -description to the load result object. Useful for debugging what was content was loaded from an
+        item provider on drop.
+
+        (-[WebItemProviderPasteboard preferredFileUploadURLAtIndex:fileType:]):
+
+        Return the highest fidelity loaded type identifier for a given item.
+
+        (-[WebItemProviderPasteboard allDroppedFileURLs]):
+        (-[WebItemProviderPasteboard typeIdentifiersToLoadForRegisteredTypeIdentfiers:]):
+
+        Prefer flat RTFD to RTFD. In the case where attachments are enabled and we're accepting all types of content
+        using attachment elements as a fallback representation, if the source writes attributed strings to the
+        pasteboard with com.apple.rtfd at a higher fidelity than com.apple.flat-rtfd, we'll end up loading only
+        com.apple.rtfd and dropping the text as an attachment element because we cannot convert the dropped content to
+        markup. Instead, if flat RTFD is present in the item provider, always prefer that over RTFD so that dropping as
+        regular web content isn't overridden when attachment elements are enabled.
+
+        (-[WebItemProviderPasteboard doAfterLoadingProvidedContentIntoFileURLs:synchronousTimeout:]):
+        (-[WebItemProviderPasteboard droppedFileURLs]): Deleted.
+        * platform/mac/DragDataMac.mm:
+        (WebCore::DragData::containsCompatibleContent const):
+
+        DragData::containsCompatibleContent should be true when attachment elements are enabled, and there are files we
+        can drop as attachment elements.
+
+        * platform/mac/PasteboardMac.mm:
+        (WebCore::Pasteboard::read):
+        (WebCore::Pasteboard::readFilePaths):
+        (WebCore::Pasteboard::readFilenames): Deleted.
+
 2018-01-03  Ting-Wei Lan  <[email protected]>
 
         Replace hard-coded paths in shebangs with #!/usr/bin/env

Source/WebCore/WebCore.xcodeproj/project.pbxproj

@@ -4653,6 +4653,7 @@
 		F48223101E3869B80066FC79 /* WebItemProviderPasteboard.mm in Sources */ = {isa = PBXBuildFile; fileRef = F482230E1E3869B80066FC79 /* WebItemProviderPasteboard.mm */; };
 		F48223111E3869B80066FC79 /* WebItemProviderPasteboard.h in Headers */ = {isa = PBXBuildFile; fileRef = F482230F1E3869B80066FC79 /* WebItemProviderPasteboard.h */; settings = {ATTRIBUTES = (Private, ); }; };
 		F48223131E386E240066FC79 /* AbstractPasteboard.h in Headers */ = {isa = PBXBuildFile; fileRef = F48223121E386E240066FC79 /* AbstractPasteboard.h */; settings = {ATTRIBUTES = (Private, ); }; };
+		F49786881FF45FA500E060AB /* PasteboardItemInfo.h in Headers */ = {isa = PBXBuildFile; fileRef = F49786871FF45FA500E060AB /* PasteboardItemInfo.h */; settings = {ATTRIBUTES = (Private, ); }; };
 		F4BFB9851E1DDF9B00862C24 /* DumpEditingHistory.js in Copy Scripts */ = {isa = PBXBuildFile; fileRef = F48389831E1DDF2B0076B7EA /* DumpEditingHistory.js */; };
 		F4BFB9861E1DDF9B00862C24 /* EditingHistoryUtil.js in Copy Scripts */ = {isa = PBXBuildFile; fileRef = F48389841E1DDF2B0076B7EA /* EditingHistoryUtil.js */; };
 		F50664F8157F52DC00AC226F /* FormController.h in Headers */ = {isa = PBXBuildFile; fileRef = F50664F6157F52DC00AC226F /* FormController.h */; };
@@ -14086,6 +14087,7 @@
 		F48223121E386E240066FC79 /* AbstractPasteboard.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = AbstractPasteboard.h; sourceTree = "<group>"; };
 		F48389831E1DDF2B0076B7EA /* DumpEditingHistory.js */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.javascript; name = DumpEditingHistory.js; path = Scripts/DumpEditingHistory.js; sourceTree = "<group>"; };
 		F48389841E1DDF2B0076B7EA /* EditingHistoryUtil.js */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.javascript; name = EditingHistoryUtil.js; path = Scripts/EditingHistoryUtil.js; sourceTree = "<group>"; };
+		F49786871FF45FA500E060AB /* PasteboardItemInfo.h */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.c.h; path = PasteboardItemInfo.h; sourceTree = "<group>"; };
 		F50664F5157F52DC00AC226F /* FormController.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = FormController.cpp; sourceTree = "<group>"; };
 		F50664F6157F52DC00AC226F /* FormController.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = FormController.h; sourceTree = "<group>"; };
 		F513A3E915FF4841001526DB /* ValidationMessageClient.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = ValidationMessageClient.h; sourceTree = "<group>"; };
@@ -23691,6 +23693,7 @@
 				4184F5151EAF059800F18BF0 /* OrientationNotifier.h */,
 				2EE02A1E1F7324280006AF72 /* Pasteboard.cpp */,
 				4B2708C50AF19EE40065127F /* Pasteboard.h */,
+				F49786871FF45FA500E060AB /* PasteboardItemInfo.h */,
 				C5F765B414E1D414006C899B /* PasteboardStrategy.h */,
 				1AF5E4D21E56735A004A1F01 /* PasteboardWriterData.cpp */,
 				1AF5E4D31E56735A004A1F01 /* PasteboardWriterData.h */,
@@ -28690,6 +28693,7 @@
 				536D5A23193E8E0C00CE4CAB /* ParsingUtilities.h in Headers */,
 				F55B3DCA1251F12D003EF269 /* PasswordInputType.h in Headers */,
 				4B2708C70AF19EE40065127F /* Pasteboard.h in Headers */,
+				F49786881FF45FA500E060AB /* PasteboardItemInfo.h in Headers */,
 				C598905714E9C28000E8D18B /* PasteboardStrategy.h in Headers */,
 				1AF5E4E31E5779B1004A1F01 /* PasteboardWriter.h in Headers */,
 				1AF5E4D51E56735B004A1F01 /* PasteboardWriterData.h in Headers */,

Source/WebCore/editing/WebContentReader.cpp

@@ -31,6 +31,14 @@
 
 namespace WebCore {
 
+DocumentFragment& WebContentReader::ensureFragment()
+{
+    ASSERT(frame.document());
+    if (!fragment)
+        fragment = frame.document()->createDocumentFragment();
+    return *fragment;
+}
+
 void WebContentReader::addFragment(Ref<DocumentFragment>&& newFragment)
 {
     if (!fragment)

Source/WebCore/editing/WebContentReader.h

@@ -63,12 +63,13 @@ class WebContentReader final : public FrameWebContentReader {
     {
     }
 
+    DocumentFragment& ensureFragment();
     void addFragment(Ref<DocumentFragment>&&);
 
 private:
 #if PLATFORM(COCOA)
     bool readWebArchive(SharedBuffer&) override;
-    bool readFilenames(const Vector<String>&) override;
+    bool readFilePaths(const Vector<String>&) override;
     bool readHTML(const String&) override;
     bool readRTFD(SharedBuffer&) override;
     bool readRTF(SharedBuffer&) override;
@@ -90,7 +91,7 @@ class WebContentMarkupReader final : public FrameWebContentReader {
 private:
 #if PLATFORM(COCOA)
     bool readWebArchive(SharedBuffer&) override;
-    bool readFilenames(const Vector<String>&) override { return false; }
+    bool readFilePaths(const Vector<String>&) override { return false; }
     bool readHTML(const String&) override;
     bool readRTFD(SharedBuffer&) override;
     bool readRTF(SharedBuffer&) override;

Source/WebCore/editing/cocoa/WebContentReaderCocoa.mm

@@ -596,4 +596,34 @@ static String stripMicrosoftPrefix(const String& string)
     return fragment;
 }
 
+bool WebContentReader::readFilePaths(const Vector<String>& paths)
+{
+    if (paths.isEmpty() || !frame.document())
+        return false;
+
+    auto& document = *frame.document();
+    bool readAnyFilePath = false;
+    for (auto& path : paths) {
+#if ENABLE(ATTACHMENT_ELEMENT)
+        if (RuntimeEnabledFeatures::sharedFeatures().attachmentElementEnabled()) {
+            auto attachment = HTMLAttachmentElement::create(HTMLNames::attachmentTag, document);
+            attachment->setUniqueIdentifier(createCanonicalUUIDString());
+            attachment->setFile(File::create(path), HTMLAttachmentElement::UpdateDisplayAttributes::Yes);
+            ensureFragment().appendChild(attachment);
+            readAnyFilePath = true;
+            continue;
+        }
+#endif
+#if PLATFORM(MAC)
+        // FIXME: Does (and should) any macOS client depend on inserting file paths as plain text in web content?
+        // If not, we should just remove this.
+        auto paragraph = createDefaultParagraphElement(document);
+        paragraph->appendChild(document.createTextNode(userVisibleString([NSURL fileURLWithPath:path])));
+        ensureFragment().appendChild(paragraph);
+        readAnyFilePath = true;
+#endif
+    }
+    return readAnyFilePath;
+}
+
 }

Source/WebCore/editing/ios/WebContentReaderIOS.mm

@@ -47,11 +47,6 @@
 
 namespace WebCore {
 
-bool WebContentReader::readFilenames(const Vector<String>&)
-{
-    return false;
-}
-
 bool WebContentReader::readURL(const URL& url, const String& title)
 {
     if (url.isEmpty())

Source/WebCore/editing/mac/WebContentReaderMac.mm

@@ -38,49 +38,15 @@
 #import "FrameLoader.h"
 #import "FrameLoaderClient.h"
 #import "HTMLAnchorElement.h"
-#import "HTMLAttachmentElement.h"
 #import "HTMLNames.h"
 #import "LegacyWebArchive.h"
-#import "MIMETypeRegistry.h"
-#import "RuntimeEnabledFeatures.h"
 #import "Settings.h"
 #import "Text.h"
 #import "WebCoreNSURLExtras.h"
 #import "markup.h"
-#import <wtf/UUID.h>
 
 namespace WebCore {
 
-bool WebContentReader::readFilenames(const Vector<String>& paths)
-{
-    if (paths.isEmpty())
-        return false;
-
-    if (!frame.document())
-        return false;
-    Document& document = *frame.document();
-
-    fragment = document.createDocumentFragment();
-
-    for (auto& text : paths) {
-#if ENABLE(ATTACHMENT_ELEMENT)
-        if (RuntimeEnabledFeatures::sharedFeatures().attachmentElementEnabled()) {
-            auto attachment = HTMLAttachmentElement::create(HTMLNames::attachmentTag, document);
-            attachment->setUniqueIdentifier(createCanonicalUUIDString());
-            attachment->setFile(File::create([NSURL fileURLWithPath:text].path), HTMLAttachmentElement::UpdateDisplayAttributes::Yes);
-            fragment->appendChild(attachment);
-            continue;
-        }
-#else
-        auto paragraph = createDefaultParagraphElement(document);
-        paragraph->appendChild(document.createTextNode(userVisibleString([NSURL fileURLWithPath:text])));
-        fragment->appendChild(paragraph);
-#endif
-    }
-
-    return true;
-}
-
 bool WebContentReader::readURL(const URL& url, const String& title)
 {
     if (url.string().isEmpty())

Source/WebCore/page/mac/DragControllerMac.mm

@@ -45,6 +45,7 @@
 #import "PasteboardStrategy.h"
 #import "PlatformStrategies.h"
 #import "Range.h"
+#import "RuntimeEnabledFeatures.h"
 
 #if ENABLE(DATA_INTERACTION)
 #import <MobileCoreServices/MobileCoreServices.h>
@@ -125,8 +126,14 @@
         supportedTypes.append(kUTTypePlainText);
         break;
     case DragHandlingMethod::EditRichText:
-        for (NSString *type in Pasteboard::supportedWebContentPasteboardTypes())
-            supportedTypes.append(type);
+        if (RuntimeEnabledFeatures::sharedFeatures().attachmentElementEnabled()) {
+            supportedTypes.append(WebArchivePboardType);
+            supportedTypes.append(kUTTypeContent);
+            supportedTypes.append(kUTTypeItem);
+        } else {
+            for (NSString *type in Pasteboard::supportedWebContentPasteboardTypes())
+                supportedTypes.append(type);
+        }
         break;
     default:
         for (NSString *type in Pasteboard::supportedFileUploadPasteboardTypes())

Source/WebCore/platform/Pasteboard.h

@@ -26,6 +26,7 @@
 #pragma once
 
 #include "DragImage.h"
+#include "PasteboardItemInfo.h"
 #include "URL.h"
 #include <wtf/HashMap.h>
 #include <wtf/ListHashSet.h>
@@ -134,7 +135,7 @@ class PasteboardWebContentReader {
 
 #if PLATFORM(COCOA)
     virtual bool readWebArchive(SharedBuffer&) = 0;
-    virtual bool readFilenames(const Vector<String>&) = 0;
+    virtual bool readFilePaths(const Vector<String>&) = 0;
     virtual bool readHTML(const String&) = 0;
     virtual bool readRTFD(SharedBuffer&) = 0;
     virtual bool readRTF(SharedBuffer&) = 0;
@@ -290,7 +291,7 @@ class Pasteboard {
 #endif
 
 #if PLATFORM(COCOA)
-    Vector<String> readFilenames();
+    Vector<String> readFilePaths();
     String readPlatformValueAsString(const String& domType, long changeCount, const String& pasteboardName);
     static void addHTMLClipboardTypesForCocoaType(ListHashSet<String>& resultTypes, const String& cocoaType);
     String readStringForPlatformType(const String&);