Introducing ClipboardEvent Constructor

Introducing ClipboardEvent Constructor

spec: http://www.w3.org/TR/2012/WD-clipboard-apis-20120223/#idl-def-ClipboardEventInit

This cl introduces 
- ClipboardEventInit dictionary
- Constructor for ClipboardEvent 

BUG=496394

[tanay.c, 2015-06-12 06:53:47]

tanay.c@samsung.com changed reviewers:
+ dcheng@chromium.org

[tanay.c, 2015-06-12 06:53:47]

PTAL

[dcheng, 2015-06-12 22:21:16]

Can we have a test that a synthetic clipboard event doesn't trigger the default
action? Or is that already tested elsewhere somehow?

[tanay.c, 2015-06-15 10:23:40]

On 2015/06/12 22:21:16, dcheng wrote:
> Can we have a test that a synthetic clipboard event doesn't trigger the
default
> action? Or is that already tested elsewhere somehow?

PTAL. Added a test to check that the default event is not triggered when a
synthetic event is dispatched on the div element.

[dcheng, 2015-06-17 03:00:14]

https://codereview.chromium.org/1178683007/diff/40001/LayoutTests/fast/events...
File LayoutTests/fast/events/constructors/clipboard-event-constructor.html
(right):

https://codereview.chromium.org/1178683007/diff/40001/LayoutTests/fast/events...
LayoutTests/fast/events/constructors/clipboard-event-constructor.html:63:
shouldBeEqualToString("divTag.textContent", "DefaultText");
Without a paste handler, this won't change (divs aren't editable), so this isn't
really testing anything. We also need equivalent tests for copy and cut.

Also, I'd split it out into a separate test file to make things eaiser to
follow.

[tanay.c, 2015-06-17 11:05:12]

On 2015/06/17 03:00:14, dcheng wrote:
>
https://codereview.chromium.org/1178683007/diff/40001/LayoutTests/fast/events...
> File LayoutTests/fast/events/constructors/clipboard-event-constructor.html
> (right):
> 
>
https://codereview.chromium.org/1178683007/diff/40001/LayoutTests/fast/events...
> LayoutTests/fast/events/constructors/clipboard-event-constructor.html:63:
> shouldBeEqualToString("divTag.textContent", "DefaultText");
> Without a paste handler, this won't change (divs aren't editable), so this
isn't
> really testing anything. We also need equivalent tests for copy and cut.
> 
> Also, I'd split it out into a separate test file to make things eaiser to
> follow.

Thanks for the comments. Uploaded a patch with separate file to check synthetic
events for cut , copy and paste. 
PTAL.

[tanay.c, 2015-06-25 05:28:52]

tanay.c@samsung.com changed reviewers:
+ philipj@opera.com

[tanay.c, 2015-06-25 05:28:53]

Please have a look

[philipj_slow, 2015-06-26 22:16:53]

The spec you've referenced is very old please make sure everything's in sync
with https://w3c.github.io/clipboard-apis/#clipboard-event-interfaces and put
that link in ClipboardEvent.idl

[philipj_slow, 2015-06-26 22:16:53]

The spec you've referenced is very old please make sure everything's in sync
with https://w3c.github.io/clipboard-apis/#clipboard-event-interfaces and put
that link in ClipboardEvent.idl

[philipj_slow, 2015-06-26 22:16:53]

The spec you've referenced is very old please make sure everything's in sync
with https://w3c.github.io/clipboard-apis/#clipboard-event-interfaces and put
that link in ClipboardEvent.idl

[philipj_slow, 2015-06-26 22:19:07]

Well that was a record number of duplicate comments...

[philipj_slow, 2015-06-26 22:37:43]

philipj@opera.com changed reviewers:
+ rbyers@chromium.org

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

Add rbyers@ to the mix since he's into events and stuff.

The spec is strange and I think it probably needs to be fixed a bit in order to
be implemented. It looks like Firefox doesn't actually do what it says either,
at least juding by this:
new ClipboardEvent({data:'foo',dataType:'text/plain'}).clipboardData.types

https://codereview.chromium.org/1178683007/diff/60001/Source/core/events/Clip...
File Source/core/events/ClipboardEvent.cpp (right):

https://codereview.chromium.org/1178683007/diff/60001/Source/core/events/Clip...
Source/core/events/ClipboardEvent.cpp:47: if (initializer.hasDataType())
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.

https://codereview.chromium.org/1178683007/diff/60001/Source/core/events/Clip...
File Source/core/events/ClipboardEventInit.idl (right):

https://codereview.chromium.org/1178683007/diff/60001/Source/core/events/Clip...
Source/core/events/ClipboardEventInit.idl:5: //
http://www.w3.org/TR/2012/WD-clipboard-apis-20120223/#idl-def-ClipboardEventInit
Link to https://w3c.github.io/clipboard-apis/#clipboard-event-interfaces here
and in ClipboardEvent.idl

[philipj_slow, 2015-06-30 10:29:52]

I've filed a spec bug:
https://github.com/w3c/clipboard-apis/issues/10

Perhaps we should wait for some feedback on that. Rick, please chime in if you
see other issues we need to deal with.

[Rick Byers, 2015-07-02 13:50:28]

On 2015/06/30 10:29:52, philipj wrote:
> I've filed a spec bug:
> https://github.com/w3c/clipboard-apis/issues/10
> 
> Perhaps we should wait for some feedback on that. Rick, please chime in if you
> see other issues we need to deal with.

I don't see anything else obviously problematic, but I don't really have any
experience with clipboard APIs (dcheng is the expert).  Also cc tkent as DOM
events expert.  I'll leave this review to you two.

[Rick Byers, 2015-07-02 13:50:39]

rbyers@chromium.org changed reviewers:
- rbyers@chromium.org

[philipj_slow, 2015-07-28 11:21:41]

https://github.com/w3c/clipboard-apis/issues/10 was resolved by making the
constructor's second argument simply an EventInitDict so that it's not possible
to supply a DataTransfer object.

I've asked for confirmation that Gecko's implementor(s) are OK with this change,
but it should be pretty easy to adapt this CL to match the new spec I think.