Where would one get a DataTransfer to hand to the ClipboardEvent constructor? about clipboard-apis HOT 16 CLOSED

I should also add that the example in the spec at https://w3c.github.io/clipboard-apis/#clipboard-event-interfaces says:

var pasteEvent = new ClipboardEvent('paste');
pasteEvent.clipboardData.items.add('My string', 'text/plain');

which would throw if the spec were actually implemented as currently written...

from clipboard-apis.

We have a need for a DataTransfer constructor for the async Clipboard API.

For this use case, the DataTransfer would be created with an empty drag-data-store and with Read/Write access. Items would be added into the store after the DataTransfer was created.

[1] Clipboard API proposal: https://github.com/garykac/clipboard/blob/master/clipboard.md
[2] Async Clipboard API: https://w3c.github.io/clipboard-apis/#clipboard-interface

from clipboard-apis.

Looks like what Firefox ships is what was defined in https://www.w3.org/TR/2015/WD-clipboard-apis-20150421/ and then it got changed to the current thing by the time https://www.w3.org/TR/2015/WD-clipboard-apis-20151215/ got published.

from clipboard-apis.

Thanks for raising this Boris. A common use case for Event constructors is to clone / wrap an event with a few changes (eg. I see event delegation libraries do this sometimes). That use case would still be possible with this as spec'd today, right?

In general I think DOM folks (@annevk, @smaug---- IIRC) have said we want event constructors to follow a pretty rigid pattern of just taking the Event attributes directly and not having any smarts / conversions. If we agree to that pattern then I suggest we proceed with shipping the constructor as speced now in blink, and explore adding ways to create DataTransfer objects (possibly low priority though). WDYT?

from clipboard-apis.

That use case would still be possible, right?

That's correct.

The rest of the questions are probably better directed at @smaug----

from clipboard-apis.

The rest of the questions are probably better directed at @smaug----

Thanks. Let me know if you think this issue should delay blink shipping the ClipboardEvent constructor though. There's no real urgency there except that we're doing a systematic pass at fixing lots of minor spec conformance issues to enable some tooling that auto-flags spec conformance issues.

from clipboard-apis.

The real question is whether there are sites depending on the Firefox behavior. I'd expect not, so shipping this in Blink is probably fine. We should just define some constructor bits for DataTransfer to make this all sane. @annevk @domenic

from clipboard-apis.

The weirdness with DataTransfer was previously discussed in #10 and it ended up looking like DragEvent, which also has a pretty useless constructor.

A DataTransfer constructor would be useful for tests of ClipboardEvent and DragEvent, I agree.

+@LoonyBean

from clipboard-apis.

I agree that DataTransfer having a ctor could be useful for testing. And even without that passing dataTransfer from trusted drag event to clipboard event might simplify some scripts.

from clipboard-apis.

@smaug---- can you help explain how such a constructor would work, over in whatwg/html#2190 ?

from clipboard-apis.

Not sure what to explain there. While handling some dnd event, one may want to dispatch untrusted clipboard event (and initialize the dataTransfer using the object from dnd).

from clipboard-apis.

@smaug---- how do you initialize the DataTransfer object "using the object from the dnd"? If we are talking about the same "object", then that object is a spec abstract data structure (the "drag data store"), and there's no way to copy it over.

from clipboard-apis.

There is no copying. DragEvents have
readonly attribute DataTransfer? dataTransfer;
and ClipboardEvents have
readonly attribute DataTransfer? clipboardData;

One can reuse the same DataTransfer object in ClipboardEvents.

something like
`
element.ondrop = function(e) {
element.dispatchEvent(new ClipboardEvent("paste", {clipboardData: e.dataTransfer}));
}

element.onpaste = function(e) {
// handle paste and drop...
}
`

Or are we talking about different things here?

from clipboard-apis.

Yes, we appear to be talking about different things. I am responding to your claim that

I agree that DataTransfer having a ctor could be useful

by asking how such a constructor could work. But your example does not include any usage of the DataTransfer constructor, so now I am confused why you think a constructor would be useful.

from clipboard-apis.

A constructor was added to DataTransfer in whatwg/html@688a102

from clipboard-apis.

Looks like there aren't any tests for new ClipboardEvent that use the new constructor, I filed web-platform-tests/wpt#7857.

from clipboard-apis.