Implement ClipboardItem
Categories
(Core :: DOM: Events, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox87 | --- | fixed |
People
(Reporter: tt, Assigned: evilpie)
References
(Blocks 1 open bug, )
Details
(Keywords: dev-doc-complete, parity-chrome)
Attachments
(4 files, 2 obsolete files)
We should implement ClipboardItem for Clipboard API.
Spec: https://w3c.github.io/clipboard-apis/
What we have at this moment: https://searchfox.org/mozilla-central/rev/d5b34cc8872177d3ee071e06f787c2a14268595b/dom/webidl/Clipboard.webidl
Wpt expected results at this moment: https://searchfox.org/mozilla-central/rev/d5b34cc8872177d3ee071e06f787c2a14268595b/testing/web-platform/meta/clipboard-apis/async-interfaces.https.html.ini
(I found bug 1619723 while I was trying to find if we have had a bug for this. I'm not sure if it's the same bug. Please feel free to mark this as a dup if someone thinks so)
Assignee | ||
Comment 1•5 years ago
|
||
Yeah. This is basically a dupe of bug 1619723, but this also has a bit more info.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
I started trying to implement this and I think Chrome doesn't actually implement what the spec says?
The ClipboardItem
constructor is defined as
constructor(record<DOMString, ClipboardItemData> items, optional ClipboardItemOptions options = {});
and ClipboardItemData
is defined as
typedef Promise<ClipboardItemDataType> ClipboardItemData;
So a valid constructor call would look something like
new ClipboardItem({"text/plain": Promise.resolve(new Blob(["hey"]))});
However Chrome seems to expect
new ClipboardItem({"text/plain": new Blob(["hey"])});
This is also what is documented on MDN: https://developer.mozilla.org/en-US/docs/Web/API/ClipboardItem
Anne do you know what is going?
Assignee | ||
Comment 4•4 years ago
|
||
Comment 5•4 years ago
|
||
Passing a normal Blob must be fine, as the IDL layer should call Promise.resolve
for them. See also: https://heycam.github.io/webidl/#es-promise
Assignee | ||
Comment 6•4 years ago
•
|
||
Okay, but passing a Promise wrapping a Blob doesn't work in Chrome. And looking at Chrome's IDL they don't use a Promise in IDL either.
[RaisesException] constructor(record<DOMString, Blob> items,
optional ClipboardItemOptions options = {});
Comment 7•4 years ago
|
||
Ah, I see. https://bugs.chromium.org/p/chromium/issues/detail?id=1014310 seems the tracking bug.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 8•4 years ago
|
||
Additionally Chrome's implementation also doesn't support presentationStyle
, lastModified
, delayed
or createDelayed
. On the other hand they have something called raw
, which seems to be disabled by default.
Honestly their interface definition would probably be a lot easier to implement, but it seems quite unfortunate that the specification is completely ignored.
Comment 9•4 years ago
|
||
Seemingly WebKit does implement the Promise way and presentationStyle
. https://webkit-search.igalia.com/webkit/rev/abf925029dfd11740099d9162279c9299ff3de85/Source/WebCore/Modules/async-clipboard/ClipboardItem.idl
Assignee | ||
Comment 10•4 years ago
|
||
Depends on D97854
Assignee | ||
Comment 11•4 years ago
•
|
||
So, I finished an implemented of clipboard.write
that can handle Blob promises. I also re0implemented clipboard.writeText
in terms of write
using a sequence of ClipboardItems.
Something I noticed however is that ClipboardItemDataType
is (DOMString or Blob)
, but ClipboardItem.getType
returns Promise<Blob>
not sure how that is supposed to work. Are we supposed to implicitly convert the promises? I can't actually find any specification of how ClipboardItem is supposed to work in that regard.
So finally probably the biggest issue I've run into: nsIClipboard
doesn't actually seems able to handle multiple transferables. That means only a single type will ever end up on the clipboard. That seems like a very serious limitation and makes all of this work of handling multiple items of multiple types sort of pointless. Am I missing something?
We write all data to index 0 so this actually probably works.
Assignee | ||
Comment 12•4 years ago
|
||
Oh and the current implementation doesn't actually work for images and probably non-text. Not sure how possible it will be to solve that.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 13•4 years ago
|
||
Assignee | ||
Comment 14•4 years ago
|
||
Depends on D97860
Comment 15•4 years ago
|
||
It seems like Kagami cleared my needinfo, thanks! I think we should aim for Safari-parity in terms of functionality (see also comments in bugs about read()
and execCommand("paste")
elsewhere) and file issues against the specification whenever it doesn't allow for Safari-parity or is nonsensical.
(It would also be ideal to make progress on bug 1676643 to ensure browsers stay consistent, but asking that from volunteers seems too much. Hopefully we can work on that next year.)
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 16•4 years ago
|
||
Nika already pointed out that holding the MozPromise in ItemEntry could leak
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 18•4 years ago
|
||
Depends on D97854
Updated•4 years ago
|
Assignee | ||
Comment 19•4 years ago
|
||
For documentation purposes:
- Firefox now supports
ClipboardItem
behind the prefdom.events.asyncClipboard.clipboardItem
, which is disabled even on Nightly. navigator.clipboard.write
now uses a sequence/list ofClipboardItem
s instead ofDataTransfer
. The pref changed fromdom.events.asyncClipboard.dataTransfer
todom.events.asyncClipboard.clipboardItem
. Also disabled by default.
Comment 20•4 years ago
|
||
Pushed by evilpies@gmail.com: https://hg.mozilla.org/integration/autoland/rev/ecc8d26d5e8a Implement ClipboardItem skeleton code r=nika https://hg.mozilla.org/integration/autoland/rev/2c1a7aba4f05 Make MozPromise::All work correctly with const r=bwc https://hg.mozilla.org/integration/autoland/rev/6a5dba78faa3 Reimplement navigator.clipboard.write to use ClipboardItem r=nika https://hg.mozilla.org/integration/autoland/rev/5029740559a7 Update tests for ClipboardItem r=nika
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/27311 for changes under testing/web-platform/tests
Comment 22•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/ecc8d26d5e8a
https://hg.mozilla.org/mozilla-central/rev/2c1a7aba4f05
https://hg.mozilla.org/mozilla-central/rev/6a5dba78faa3
https://hg.mozilla.org/mozilla-central/rev/5029740559a7
Upstream PR merged by moz-wptsync-bot
Comment 24•4 years ago
|
||
Rumyra documented all this stuff really nicely in https://github.com/mdn/content/issues/2514.
Comment 25•3 years ago
•
|
||
:evilpie: seeing the tests modified in https://bugzilla.mozilla.org/attachment.cgi?id=9190028, is ClipboardItem
's constructor already supposed to work with Promise
s? Please see https://jsfiddle.net/j76wfzt3/ for an example and some more links to Safari/Chromium issues.
Currently, it doesn't work, also with dom.events.asyncClipboard.clipboardItem
set to true
.
After clicking the "copy" button, the clipboard contains
"[object Promise]"
instead of
"<rect width="300" height="100"
style="fill:rgb(0,0,255);stroke-width:3;stroke:rgb(0,0,0)"></rect>
Sorry, your browser does not support inline SVG."
Question came up because of https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/compat2021/9yrdEPyBygQ/B685_XSwFAAJ.
Assignee | ||
Comment 26•3 years ago
|
||
No we don't support Promises in the ClipboardItem
constructor.
Comment 27•3 years ago
•
|
||
(In reply to Tom Schuster [:evilpie] from comment #26)
No we don't support Promises in the
ClipboardItem
constructor.
Thanks. Presumably, it would make sense to throw an error?
Then, the jsfiddle mentioned in #c25 would run into the catch
case, which works. See https://jsfiddle.net/80hq96ym/ for an adaptation of the above jsfiddle.
That is, the example of https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/compat2021/9yrdEPyBygQ/B685_XSwFAAJ would write the correct content to the clipboard instead of "[object Promise]".
Assignee | ||
Comment 28•3 years ago
|
||
(In reply to Mirko Brodesser (:mbrodesser) from comment #27)
(In reply to Tom Schuster [:evilpie] from comment #26)
No we don't support Promises in the
ClipboardItem
constructor.Thanks. Presumably, it would make sense to throw an error?
No. This is just how WebIDL behave. Chrome throws when passing a Promise
, because they only support Blob
and not DOMString
. We support DOMString
so we implicitly coerce to strings.
Then, the jsfiddle mentioned in #c25 would run into the
catch
case, which works. See https://jsfiddle.net/80hq96ym/ for an adaptation of the above jsfiddle.That is, the example of https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/compat2021/9yrdEPyBygQ/B685_XSwFAAJ would write the correct content to the clipboard instead of "[object Promise]".
I am going to open a new bug for adding Promise support. I think Safari should in theory support passing a normal Blob instead of Promise.resolve(blob), because the former should really automatically convert to the later.
Anyway the right solution here is for Chrome to implement the API properly or for Safari and the spec the change. We will presumably not ship this API before those questions are resolved.
Comment 29•2 years ago
|
||
(In reply to Tom Schuster [:evilpie] from comment #19)
For documentation purposes:
- Firefox now supports
ClipboardItem
behind the prefdom.events.asyncClipboard.clipboardItem
, which is disabled even on Nightly.navigator.clipboard.write
now uses a sequence/list ofClipboardItem
s instead ofDataTransfer
. The pref changed fromdom.events.asyncClipboard.dataTransfer
todom.events.asyncClipboard.clipboardItem
. Also disabled by default.
What are the current obstacles to dom.events.asyncClipboard.clipboardItem
being enabled by default?
Comment 30•2 years ago
•
|
||
It'd be nice if dom.events.asyncClipboard.clipboardItem
would be enabled by default. ClipboardItem
is required to copy images to clipboard, and I have been using it with the pref enabled for a while now without any issues.
Is there an bug to track this enablement or should we re-open this one until it is?
Description
•