Add WebDragData to blink::WebView::dragtargetDrop

content/public/common/drop_data.h

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // A struct for managing data being dropped on a WebContents.  This represents
 // a union of all the types of data that can be dropped in a platform neutral
 // way.
 
 #ifndef CONTENT_PUBLIC_COMMON_DROP_DATA_H_
 #define CONTENT_PUBLIC_COMMON_DROP_DATA_H_
@@ skipping 14 matching lines @@
 
 struct CONTENT_EXPORT DropData {
   struct FileSystemFileInfo {
     FileSystemFileInfo() : size(0) {}
     ~FileSystemFileInfo() {}
 
     GURL url;
     int64_t size;
   };
 
+  enum class Kind {
+    STRING = 0,
+    FILENAME,
+    FILESYSTEMFILE,
+    LAST = FILESYSTEMFILE
+  };
+
+  struct MetaData {

[dcheng, 2016/05/24 05:51:50]

Nit: Metadata instead of MetaData, as that seems to be more prevalent

[hush (inactive), 2016/05/24 20:26:09]

Done.

+    MetaData();
+    MetaData(const DropData::Kind& kind, const base::string16& mime_type);

[dcheng, 2016/05/24 05:51:50]

Hmm. Rather than having constructors and having to pass the kind explicitly, I
suggest something like:

MetaData::CreateForMimeType(...)
MetaData::CreateForFilePath(...)
MetaData::CreateForFilesystemUrl(...)

[hush (inactive), 2016/05/24 20:26:09]

Sorry I don't see the benefit of these static factory methods.
The kind is implicit only for CreateForFilePath and CreateForFileSystemUrl.
CreateForMimeType still needs both mime type and kind, because kind could be
both string and filename. 
These static factory methods also make "DropDataToMeta" more verbose because we
have to use push_back instead of emplace_back. And we also incur more copies as
a result of using static factory methods (one in the factory method itself, one
in push_back)

How about keeping these 3 constructors, but only pass kind when the 2nd
parameter is mime type, because that's the only case where kind is unclear?

[dcheng, 2016/05/25 00:07:58]

The main reason I suggested factory functions is to help overall readability. If
I see:

Metadata(const GURL&);

it's hard to tell it's only for filesystem URLs and not for other kinds of URLs.

But if I have:

Metadata::CreateForFilesystemUrl(...)

Then it's unambiguous.

As for the extra copy... if it really matters, we should give it a move
constructor. Otherwise we shouldn't worry about it.

[hush (inactive), 2016/05/25 02:31:16]

OK. I did the static factory methods.

+    MetaData(const DropData::Kind& kind, const base::FilePath& filename);
+    MetaData(const DropData::Kind& kind, const GURL& file_system_url);
+    MetaData(const MetaData& other);
+    ~MetaData();
+
+    DropData::Kind kind;
+    base::string16 mime_type;
+    base::FilePath filename;
+    GURL file_system_url;
+  };
+
   DropData();
   DropData(const DropData& other);
   ~DropData();
 
   // Whether this drag originated from a renderer.
   bool did_originate_from_renderer;
 
   // User is dragging a link into the webview.
   GURL url;
   base::string16 url_title;  // The title associated with |url|.
 
   // User is dragging a link out-of the webview.
   base::string16 download_metadata;
 
   // Referrer policy to use when dragging a link out of the webview results in
   // a download.
   blink::WebReferrerPolicy referrer_policy;
 
   // User is dropping one or more files on the webview. This field is only
   // populated if the drag is not renderer tainted, as this allows File access
   // from web content.
   std::vector<ui::FileInfo> filenames;
+  // The mime types of dragged files.
+  std::vector<base::string16> file_mime_types;
 
   // Isolated filesystem ID for the files being dragged on the webview.
   base::string16 filesystem_id;
 
   // User is dragging files specified with filesystem: URLs.
   std::vector<FileSystemFileInfo> file_system_files;
 
   // User is dragging plain text into the webview.
   base::NullableString16 text;
 
   // User is dragging text/html into the webview (e.g., out of Firefox).
   // |html_base_url| is the URL that the html fragment is taken from (used to
   // resolve relative links).  It's ok for |html_base_url| to be empty.
   base::NullableString16 html;
   GURL html_base_url;
 
   // User is dragging data from the webview (e.g., an image).
   base::string16 file_description_filename;
   std::string file_contents;
 
   std::map<base::string16, base::string16> custom_data;
 };
 
 }  // namespace content
 
 #endif  // CONTENT_PUBLIC_COMMON_DROP_DATA_H_