Intent to Ship: ClipboardEvent Constructor

[Luna]

Spec https://w3c.github.io/clipboard-apis/#clipboard-event-interfaces

Summary This entry tracks exposing ClipboardEvent constructor.

Interoperability risk Firefox: No public signals Edge: No public signals Safari: No public signals

OWP launch tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=496394

Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/4687833935642624

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes

[Philip Jägenstedt]

LGTM1

[Rick Byers]

LGTM2 - tiny and obviously correct (despite not being in any other browsers yet).

[Dimitri Glazkov]

LGTM3

[Boris Zbarsky]

On 12/16/16 8:51 AM, Luna wrote:
> Interoperability risk
> Firefox: No public signals

The ClipboardEvent constructor has been shipping in Firefox since at
least 2013.

That said, it looks like it was based on the spec draft at the time [1],
and doesn't match the current spec draft. Specifically, the current
spec draft has:

dictionary ClipboardEventInit : EventInit {
DataTransfer? clipboardData = null;
};

whereas what Firefox is shipping has:

dictionary ClipboardEventInit : EventInit
{
DOMString data = "";
DOMString dataType = "";
};

and inside the constructor creates a DataTransfer with that data and
that dataType.

I've raised https://github.com/w3c/clipboard-apis/issues/33 because as
currently written in the spec this constructor is pretty much unusable.

-Boris

[1] https://www.w3.org/TR/2015/WD-clipboard-apis-20150421/ has the
dictionary the way Firefox is shipping it.
https://www.w3.org/TR/2015/WD-clipboard-apis-20151215/ looks like it
changed to the new setup.

[Rick Byers]

Thanks Boris!  I've replied on the spec issue.

[Lucas Garron]

+garykac, +Daniel Cheng 

What is the main purpose of shipping it now?

There are a few clipboard efforts underway in Chromium right now, including a new clipboard API whose current proposal draft uses DataTransfer instead of Clipboard Event and some extension APIs?
Is this related to one of them, or is there a separate reason to ship this now?

»Lucas

[Rick Byers]

This is just part of a larger effort at spec conformance (using some new automated tools we've working on to identify issues between blink's IDL files and the IDL in specs).  There's no particular urgency, but I also don't think there's any good reason not to do this (unless I'm missing something?).  Even if/when we do a new API, we'll still want to follow the standard constructor patterns for the original API for consistency.

[Lucas Garron]

Last I heard, the editing spec had a big warning on it and the separate clipboard API wasn't going anywhere (which is why we were trying to work on a better one).

But I just noticed that garykac@ joined Hallvord on the spec in the first post of this thread, so I trust they know what they're doing.

»Lucas