Introducing ClipboardEvent Constructor

Source/core/events/ClipboardEvent.cpp

Index: Source/core/events/ClipboardEvent.cpp
diff --git a/Source/core/events/ClipboardEvent.cpp b/Source/core/events/ClipboardEvent.cpp
index 22992c3ec0003cbf721a7f75cc516b4f503e4714..f857fc566babeeea7c030a0131b8cbd0c4bc8cfa 100644
--- a/Source/core/events/ClipboardEvent.cpp
+++ b/Source/core/events/ClipboardEvent.cpp
@@ -22,6 +22,7 @@
 
 #include "config.h"
 #include "core/events/ClipboardEvent.h"
+#include "core/clipboard/DataObject.h"
 
 namespace blink {
 
@@ -34,6 +35,19 @@ ClipboardEvent::ClipboardEvent(const AtomicString& eventType, bool canBubble, bo
 {
 }
 
+ClipboardEvent::ClipboardEvent(const AtomicString& type, const ClipboardEventInit& initializer)
+    : Event(type, initializer)
+{
+    DataTransferAccessPolicy policy = DataTransferNumb;
+
+    if (type == EventTypeNames::copy || type == EventTypeNames::cut || type == EventTypeNames::paste)
+        policy = DataTransferWritable;
+
+    m_clipboardData = DataTransfer::create(DataTransfer::CopyAndPaste, policy, DataObject::create());
+    if (initializer.hasDataType())

[philipj_slow, 2015/06/26 22:37:44]

The hasDataType() isn't needed because this member has a default value in the
IDL.

Also, the spec expresses this differently, and is pretty weird to me. As part of
"fire a clipboard event" it checks if the event is trusted and uses the data and
dataType arguments from the constructor without actually storing somewhere in
the interim. If actually implemented like this, we'd have to add the entry to
the DataTransferItemList when the event is fired, not in the constructor.

Also strange is that there's no way to actually run the "fire a clipboard event"
algorithm from scripts, all of the entry points look like they're for actual
copy/paste/cut actions.

+        m_clipboardData->setData(initializer.dataType(), initializer.data());
+}
+
 ClipboardEvent::~ClipboardEvent()
 {
 }