Closed Bug 1461465 Opened 6 years ago Closed 6 years ago

Implement the Async Clipboard API

Categories

(Core :: DOM: Events, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: nika, Assigned: annyG, Mentored, NeedInfo)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete)

Attachments

(1 file, 1 obsolete file)

Priority: -- → P3
Re-assigning this to my intern :-).
Assignee: nika → agakhokidze
Mentor: nika
Attachment #8985103 - Attachment is obsolete: true
Comment on attachment 8987165 [details]
Bug 1461465 - Implement async Clipboard APIs

https://reviewboard.mozilla.org/r/252408/#review258904

::: dom/base/ShadowRoot.h:17
(Diff revision 1)
>  #include "mozilla/dom/NameSpaceConstants.h"
>  #include "nsCOMPtr.h"
>  #include "nsCycleCollectionParticipant.h"
>  #include "nsIdentifierMapEntry.h"
>  #include "nsTHashtable.h"
> +#include "nsStubMutationObserver.h"

I added some missing imports here because I was getting import failures

::: dom/events/Event.cpp:12
(Diff revision 1)
>  #include "AccessCheck.h"
>  #include "base/basictypes.h"
>  #include "ipc/IPCMessageUtils.h"
>  #include "mozilla/dom/Event.h"
>  #include "mozilla/dom/ShadowRoot.h"
> +#include "mozilla/EventDispatcher.h"

Added some missing imports again

::: toolkit/components/extensions/test/mochitest/test_ext_async_clipboard.html:305
(Diff revision 1)
> +  await extension.unload();
> +  win.close();
> +});
> +
> +// Test that performing read(...) when the clipboard is empty returns an empty data transfer
> +add_task(async function test_contentscript_clipboard_nocontents_read() {

This test is not passing yet on 32-bit linux e10s, because the clipboard is not cleared properly, but I will be investigating it next week to see how to properly clear the clipboard
Attachment #8987165 - Flags: review?(enndeakin)
Did you get your wpt issues we discussed at the all hands figured out, or are you still having issues? I poked some at AH but was too tired to get much done, can start helping again if you'd like and it's not fixed.
Flags: needinfo?(agakhokidze)
jgraham suggested that I make a change to modules/libpref/init/all.js so that the tests know how to disable the prefs, and it worked :) Thanks for checking up!
Flags: needinfo?(agakhokidze)
Comment on attachment 8987165 [details]
Bug 1461465 - Implement async Clipboard APIs

https://reviewboard.mozilla.org/r/252408/#review262182

::: dom/base/Navigator.h:273
(Diff revision 6)
>    RefPtr<Geolocation> mGeolocation;
>    RefPtr<battery::BatteryManager> mBatteryManager;
>    RefPtr<Promise> mBatteryPromise;
>    RefPtr<network::Connection> mConnection;
>    RefPtr<CredentialsContainer> mCredentials;
> +  RefPtr<dom::Clipboard> mClipboard;

Is the 'dom::' needed here? Similar in other places in this patch.

::: dom/base/ShadowRoot.h:20
(Diff revision 6)
>  #include "nsCOMPtr.h"
>  #include "nsCycleCollectionParticipant.h"
>  #include "nsIdentifierMapEntry.h"
>  #include "nsStubMutationObserver.h"
>  #include "nsTHashtable.h"
> +#include "nsStubMutationObserver.h"

The first two are already included a few lines earlier.

::: dom/events/Clipboard.h:53
(Diff revision 6)
> +
> +  virtual JSObject*
> +  WrapObject(JSContext* aCx, JS::Handle<JSObject*> aGivenProto) override;
> +
> +private:
> +  // Checks if dom.events.testing.asyncClipboard pref is enabled.

Not sure if I like the idea of adding another preference to enable bypassing security checks. Looking at the tests, it seems that we only run the tests with this preference enabled. Why do we need to bypass these checks in tests when it doesn't test any real usage?

::: dom/events/Clipboard.cpp:17
(Diff revision 6)
> +#include "nsComponentManagerUtils.h"
> +#include "nsITransferable.h"
> +#include "nsArrayUtils.h"
> +#include "mozilla/dom/DataTransfer.h"
> +#include "mozilla/dom/DataTransferItemList.h"
> +#include "mozilla/dom/DataTransferItem.h"

The mozilla/dom includes should be together, and in alphabetical order.

::: dom/events/Clipboard.cpp:40
(Diff revision 6)
> +
> +}
> +
> +already_AddRefed<Promise>
> +Clipboard::ReadHelper(JSContext* aCx, nsIPrincipal& aSubjectPrincipal,
> +                      ErrorResult& aRv, ClipboardReadType aClipboardReadType)

The error result (aRv) should be the last argument.

::: dom/events/Clipboard.cpp:76
(Diff revision 6)
> +            MOZ_LOG(GetClipboardLog(), LogLevel::Debug,
> +                    ("Clipboard, ReadHelper, read case\n"));
> +            p->MaybeResolve(dataTransfer);
> +            break;
> +          case eReadText:
> +            MOZ_LOG(GetClipboardLog(), LogLevel::Debug,

The eReadText case gets the text (using GetData), yet also calls FillAllExternalData.

::: dom/events/Event.cpp:39
(Diff revision 6)
>  #include "nsIScrollableFrame.h"
>  #include "nsJSEnvironment.h"
>  #include "nsLayoutUtils.h"
>  #include "nsPIWindowRoot.h"
>  #include "nsRFPService.h"
> +#include "nsStubMutationObserver.h"

This doesn't seem to be used directly in Event.cpp

::: toolkit/components/extensions/test/mochitest/test_ext_async_clipboard.html:22
(Diff revision 6)
> +function shared() {
> +  this.clipboardWriteText = function(txt) {
> +    return navigator.clipboard.writeText(txt);
> +  };
> +
> +  this.clipboardWrite = function(txt) {

'dt' not 'txt'

::: toolkit/components/extensions/test/mochitest/test_ext_async_clipboard.html:38
(Diff revision 6)
> +}
> +
> +/**
> + * Clear the clipboard.
> + *
> + * This is needed because Services.clipboard.emptyClipboard() does not actually work.

emptyClipboard does work, but it isn't supposed to clear the actual system clipboard, which is what I think you're expecting here.

::: toolkit/components/extensions/test/mochitest/test_ext_async_clipboard.html:356
(Diff revision 6)
> +  await extension.unload();
> +  win.close();
> +});
> +</script>
> +</body>
> +</html>

All of these tests seem to run in the context of an extension. Is this API only meant to be used for extensions, or do we want normal page tests as well?
Attachment #8987165 - Flags: review?(enndeakin)
Attachment #8987165 - Flags: review?(amarchesini)
Comment on attachment 8987165 [details]
Bug 1461465 - Implement async Clipboard APIs

https://reviewboard.mozilla.org/r/252408/#review262956

Sorry, for the delay here. I hadn't pushed the Publish button.

I was under the impression from a message that was posted that only the Write methods were going to be implemented at this time. While the Write methods are OK (apart from it being quite unfortunate that drag and drop would need to use a different API), the Read method isn't a useful API design for asynchronous clipboard usage as you cannot get the available types separately from the data. The promise part should be on the data getters instead. I commented as such to the now former spec author when this API was first proposed but I guess that feedback went nowhere.

Indeed, the patch here adds a usage of FillAllExternalData which I want to strive to remove usages of. I'd really like to in the long run, move all of our clipboard and drag and drop code as much as possible to be entirely async, so I want to make sure that we push forward with APIs that let us do that.

I realize that you're just implementing what was was put in the spec, and the code here looks good for what it says. At least this is prefed off for now, I guess.
Attachment #8987165 - Flags: review?(enndeakin) → review-
(In reply to Neil Deakin from comment #15)
> I was under the impression from a message that was posted that only the
> Write methods were going to be implemented at this time. While the Write
> methods are OK (apart from it being quite unfortunate that drag and drop
> would need to use a different API), the Read method isn't a useful API
> design for asynchronous clipboard usage as you cannot get the available
> types separately from the data. The promise part should be on the data
> getters instead. I commented as such to the now former spec author when this
> API was first proposed but I guess that feedback went nowhere.

The plan which I was working under was that we were going to implement each of the APIs, but only turn on the readText and writeText APIs behind a pref. I think those two APIs are relatively straightforward, and are they only two ones which Chrome has implemented.

I was hoping to encourage future conversations with the chrome team about their plans for the more general read/write APIs and their current shortcomings (such as full data read requirements & the lack of an API for adding image data directly as an image and not as a File to the clipboard, etc.).

My ideal interface for the general APIs right now would probably involve them taking and returning a `DataTransferItemList` rather than a `DataTransfer`, as the getters for data on the `DataTransferItem` object are all async (getAsString takes a callback, and getAsFile returns a `File` object). That being said, spec discussions are required to make these happen.

It seemed like a reasonable idea to have an implementation of the current spec ready, and I don't think it will be too much of a problem to switch to the new spec in the future if it is needed :-). In addition, this current implementation is _not_ the most efficient possible one. Due to the design of the underlying APIs, many things are done synchronously here which need not be done synchronously. In follow-ups we may look into ways to make this more async & perform fewer synchronous calls.


> Indeed, the patch here adds a usage of FillAllExternalData which I want to
> strive to remove usages of. I'd really like to in the long run, move all of
> our clipboard and drag and drop code as much as possible to be entirely
> async, so I want to make sure that we push forward with APIs that let us do
> that.

I agree that we want to make as much of this async as possible! I think this is a first step towards having a more async and ergonomic clipboard API. This API however doesn't quite make sense for Drag & Drop, which is why I imagine it was not used to serve this purpose. I think that we can probably make Drag & Drop more efficient over time by encouraging use of the `DataTransferItemList` object over the legacy `.files`, `.types`, and `.getData` APIs.


> I realize that you're just implementing what was was put in the spec, and
> the code here looks good for what it says. At least this is prefed off for
> now, I guess.
Flags: needinfo?(enndeakin)
Comment on attachment 8987165 [details]
Bug 1461465 - Implement async Clipboard APIs

https://reviewboard.mozilla.org/r/252408/#review262182

> Is the 'dom::' needed here? Similar in other places in this patch.

Cannot change RefPtr<dom::Clipboard> mClipboard; into RefPtr<Clipboard> mClipboard; because
this is the error I get
 1:29.32  error: call to non-static member function without an object argument
 1:29.32   RefPtr<Clipboard> mClipboard;
 
It thinks I am referring to the Clipboard() function.

> The first two are already included a few lines earlier.

Oops, this must have been fixed when I rebased my work on top of the latest master.

> Not sure if I like the idea of adding another preference to enable bypassing security checks. Looking at the tests, it seems that we only run the tests with this preference enabled. Why do we need to bypass these checks in tests when it doesn't test any real usage?

I added this bypass pref because it is needed to successfully run the web platform tests. Extension tests don't need this pref enabled.

> The eReadText case gets the text (using GetData), yet also calls FillAllExternalData.

I thought DataTransfer::FillAllExternalData retrieves data from the clipboard into the data transfer, and DataTransfer::GetData allows us to retrieve data of a specific mime type from the data transfer itself.

> All of these tests seem to run in the context of an extension. Is this API only meant to be used for extensions, or do we want normal page tests as well?

Yes, per https://bugzilla.mozilla.org/show_bug.cgi?id=1462075#c1 this will only be available to extensions for now.
Comment on attachment 8987165 [details]
Bug 1461465 - Implement async Clipboard APIs

https://reviewboard.mozilla.org/r/252408/#review262990

::: dom/events/Clipboard.h:60
(Diff revisions 7 - 8)
>    //  or reading from the clipboard.
>    bool IsTestingPrefEnabled();
>  
>    already_AddRefed<Promise> ReadHelper(JSContext* aCx, nsIPrincipal& aSubjectPrincipal,
> -                                       ErrorResult& aRv, ClipboardReadType aClipboardReadType);
> +                                       ClipboardReadType aClipboardReadType, ErrorResult& aRv);
> +

Sorry, I will remove this, this appeared because of rebasing
Comment on attachment 8987165 [details]
Bug 1461465 - Implement async Clipboard APIs

https://reviewboard.mozilla.org/r/252408/#review262182

> Cannot change RefPtr<dom::Clipboard> mClipboard; into RefPtr<Clipboard> mClipboard; because
> this is the error I get
>  1:29.32  error: call to non-static member function without an object argument
>  1:29.32   RefPtr<Clipboard> mClipboard;
>  
> It thinks I am referring to the Clipboard() function.

I tried to eliminate dom:: and I got errors while doing a try build
https://treeherder.mozilla.org/logviewer.html#?job_id=187605934&repo=try&lineNumber=13630
> I thought DataTransfer::FillAllExternalData retrieves data from the
> clipboard into the data transfer, and DataTransfer::GetData allows us to
> retrieve data of a specific mime type from the data transfer itself.

GetData will fill in the data for you. This happens here: https://searchfox.org/mozilla-central/source/dom/events/DataTransferItem.cpp#486
Flags: needinfo?(enndeakin)
Comment on attachment 8987165 [details]
Bug 1461465 - Implement async Clipboard APIs

With that last comment fixed up, I think the code itself is ok.
Attachment #8987165 - Flags: review?(enndeakin) → review+
I have uploaded one more final diff to address the GetData comment. If it looks good to you, I will proceed to get it landed. Thanks! :)
Flags: needinfo?(enndeakin)
Comment on attachment 8987165 [details]
Bug 1461465 - Implement async Clipboard APIs

https://reviewboard.mozilla.org/r/252408/#review264950

::: dom/events/Clipboard.cpp:77
(Diff revisions 7 - 11)
> -                    ("Clipboard, ReadHelper, read case\n"));
> +                  ("Clipboard, ReadHelper, read case\n"));
> +          dataTransfer->FillAllExternalData();
> +          // If there are items on the clipboard, data transfer will contain those,
> +          // else, data transfer will be empty and we will be resolving with an empty data transfer
> -            p->MaybeResolve(dataTransfer);
> +          p->MaybeResolve(dataTransfer);
> -            break;
> +          return;

You should use 'break' here rather than return, and ideally add a break in the eReadText case. That way someone adding other cases or modifying the code is less likely to be surprised by uncoventional code.
Attachment #8987165 - Flags: review?(enndeakin) → review+
hg error in cmd: hg push -r tip ssh://hg.mozilla.org/integration/autoland: pushing to ssh://hg.mozilla.org/integration/autoland
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 20 changes to 20 files
remote: 
remote: ******************************* ERROR *******************************
remote: Changeset e64c47c2c06c alters WebIDL file(s) without DOM peer review:
remote: dom/webidl/Clipboard.webidl
remote: dom/webidl/Navigator.webidl
remote: 
remote: Please, request review from either:
remote:   - Andrea Marchesini (:baku)
remote:   - Andrew McCreight (:mccr8)
remote:   - Ben Kelly (:bkelly)
remote:   - Blake Kaplan (:mrbkap)
remote:   - Bobby Holley (:bholley)
remote:   - Boris Zbarsky (:bz)
remote:   - Ehsan Akhgari (:ehsan)
remote:   - Henri Sivonen (:hsivonen)
remote:   - Kyle Machulis (:qdot)
remote:   - Nika Layzell (:mystor)
remote:   - Olli Pettay (:smaug)
remote:   - Peter Van der Beken (:peterv)
remote: *********************************************************************
remote: 
remote: transaction abort!
remote: rollback completed
remote: pretxnchangegroup.mozhooks hook failed
abort: push failed on remote
Comment on attachment 8987165 [details]
Bug 1461465 - Implement async Clipboard APIs

https://reviewboard.mozilla.org/r/252408/#review265230

::: dom/events/Clipboard.cpp:24
(Diff revision 12)
> +#include "nsArrayUtils.h"
> +
> +
> +static mozilla::LazyLogModule gClipboardLog("Clipboard");
> +
> +#define ASYNC_CLIPBOARD_TESTING_PREF "dom.events.testing.asyncClipboard"

nit: Just use the string literal in the once place it is used, I think it's pretty clear what it represents without a define :-)

::: dom/events/Clipboard.cpp:32
(Diff revision 12)
> +namespace dom {
> +
> +Clipboard::Clipboard(nsPIDOMWindowInner* aWindow)
> +: DOMEventTargetHelper(aWindow)
> +{
> +

nit: remove this empty line

::: dom/events/Clipboard.cpp:37
(Diff revision 12)
> +
> +}
> +
> +Clipboard::~Clipboard()
> +{
> +

nit: remove this empty line

::: dom/events/Clipboard.cpp:175
(Diff revision 12)
> +  // We create a data transfer with text/plain format so that
> +  //  we can reuse Clipboard::Write(...) member function
> +  RefPtr<DataTransfer> dataTransfer = new DataTransfer(this, eCopy,
> +                                                      /* is external */ true,
> +                                                      /* clipboard type */ -1);
> +  NS_NAMED_LITERAL_STRING(format, "text/plain");

Please use NS_LITERAL_STRING(kTextMime) in SetData instead of defining a new named literal string here.

::: dom/webidl/Clipboard.webidl:14
(Diff revision 12)
> + * Copyright © 2018 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C
> + * liability, trademark and document use rules apply.
> + */
> +
> +
> +[SecureContext, Exposed=Window, Pref="dom.events.asyncClipboard"] interface Clipboard : EventTarget {

nit: newline before 'interface'

::: testing/web-platform/tests/clipboard-apis/async-interfaces.https.html:18
(Diff revision 12)
>    var idl_array = new IdlArray();
>    idl_array.add_untested_idls('interface Navigator {};');
>    idl_array.add_untested_idls('interface EventTarget {};');
>    idl_array.add_untested_idls('dictionary PermissionDescriptor {};');
>    idl_array.add_untested_idls(dom, { only: ['Event', 'EventInit'] });
> +  idl_array.add_untested_idls('interface DataTransfer {};');

I'm not sure whether or not this is correct... Can you show me the code for it, and what is failing :-)?

::: toolkit/components/extensions/test/mochitest/test_ext_async_clipboard.html:52
(Diff revision 12)
> +  await SpecialPowers.pushPrefEnv({"set": [["dom.events.asyncClipboard", true]]});
> +  await SpecialPowers.pushPrefEnv({"set": [["dom.events.asyncClipboard.dataTransfer", true]]});
> +});

nit: the double array in "set": actually exists so you can set multiple prefs with one call!

::: toolkit/components/extensions/test/mochitest/test_ext_async_clipboard.html:318
(Diff revision 12)
> +      // and kind string, but we can't call getAsString on it
> +      // to verify that at least it is an empty string.

I presume if we call getAsString we never get the callback invoked?
Comment on attachment 8987165 [details]
Bug 1461465 - Implement async Clipboard APIs

https://reviewboard.mozilla.org/r/252408/#review265236

::: testing/web-platform/tests/clipboard-apis/async-interfaces.https.html:18
(Diff revision 12)
>    var idl_array = new IdlArray();
>    idl_array.add_untested_idls('interface Navigator {};');
>    idl_array.add_untested_idls('interface EventTarget {};');
>    idl_array.add_untested_idls('dictionary PermissionDescriptor {};');
>    idl_array.add_untested_idls(dom, { only: ['Event', 'EventInit'] });
> +  idl_array.add_untested_idls('interface DataTransfer {};');

`FAIL ClipboardEvent interface: new ClipboardEvent("x") must inherit property "clipboardData" with the proper type - Unrecognized type DataTransfer`
 
 
 This is the failure
Comment on attachment 8987165 [details]
Bug 1461465 - Implement async Clipboard APIs

https://reviewboard.mozilla.org/r/252408/#review265230

> I'm not sure whether or not this is correct... Can you show me the code for it, and what is failing :-)?

FAIL ClipboardEvent interface: new ClipboardEvent("x") must inherit property "clipboardData" with the proper type - Unrecognized type DataTransfer


This is the failure
Comment on attachment 8987165 [details]
Bug 1461465 - Implement async Clipboard APIs

https://reviewboard.mozilla.org/r/252408/#review265554

r=me if we just mark the one WPT failure as an expected failure.

::: testing/web-platform/tests/clipboard-apis/async-interfaces.https.html:18
(Diff revision 13)
>    var idl_array = new IdlArray();
>    idl_array.add_untested_idls('interface Navigator {};');
>    idl_array.add_untested_idls('interface EventTarget {};');
>    idl_array.add_untested_idls('dictionary PermissionDescriptor {};');
>    idl_array.add_untested_idls(dom, { only: ['Event', 'EventInit'] });
> +  idl_array.add_untested_idls('interface DataTransfer {};');

Please remove this change & have the failure in the .ini file :-) - Thanks!
Attachment #8987165 - Flags: review?(nika) → review+
Flags: needinfo?(enndeakin)
hg error in cmd: hg push -r tip ssh://hg.mozilla.org/integration/autoland: pushing to ssh://hg.mozilla.org/integration/autoland
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 20 changes to 20 files
remote: 
remote: ******************************* ERROR *******************************
remote: Changeset bd51279ee0bf alters WebIDL file(s) without DOM peer review:
remote: dom/webidl/Clipboard.webidl
remote: dom/webidl/Navigator.webidl
remote: 
remote: Please, request review from either:
remote:   - Andrea Marchesini (:baku)
remote:   - Andrew McCreight (:mccr8)
remote:   - Ben Kelly (:bkelly)
remote:   - Blake Kaplan (:mrbkap)
remote:   - Bobby Holley (:bholley)
remote:   - Boris Zbarsky (:bz)
remote:   - Ehsan Akhgari (:ehsan)
remote:   - Henri Sivonen (:hsivonen)
remote:   - Kyle Machulis (:qdot)
remote:   - Nika Layzell (:mystor)
remote:   - Olli Pettay (:smaug)
remote:   - Peter Van der Beken (:peterv)
remote: *********************************************************************
remote: 
remote: transaction abort!
remote: rollback completed
remote: pretxnchangegroup.mozhooks hook failed
abort: push failed on remote
Pushed by nika@thelayzells.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/86bce8df5152
Part 1: Implement async Clipboard APIs, r=nika,enndeakin
Flags: needinfo?(nika)
Flags: needinfo?(nika) → needinfo?(agakhokidze)
Pushed by nika@thelayzells.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7b42110e827b
Implement async Clipboard APIs, r=nika,enndeakin
Flags: needinfo?(agakhokidze)
Hi Nika,

I uploaded some changes to the tests that were the reason for the android failure, will you please review those changes? Thanks
Flags: needinfo?(agakhokidze) → needinfo?(nika)
Comment on attachment 8987165 [details]
Bug 1461465 - Implement async Clipboard APIs

https://reviewboard.mozilla.org/r/252408/#review266498

::: toolkit/components/extensions/test/mochitest/test_ext_async_clipboard.html:301
(Diff revisions 15 - 16)
> +    if (AppConstants.platform == "android") {
> +      // On android, this clears the actual system clipboard
> +      SpecialPowers.Services.clipboard.emptyClipboard(SpecialPowers.Services.clipboard.kGlobalClipboard);
> +    } else {

nit: Can we put this call into the clearClipboard function itself, rather than changing the callsites?
Pushed by nika@thelayzells.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/647fdd384a5e
Implement async Clipboard APIs, r=nika,r=enndeakin
https://hg.mozilla.org/mozilla-central/rev/647fdd384a5e
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
See Also: → 1479935
Can this API be used from a WebExtension? I tried both in a normal web page's console and in the background script of a WebExtension I was debugging and I get "navigator.clipboard" is undefined.

Also, where is the best place to ask this sort of questions about using this API, I'm guessing Bugzilla is not a good place for this.
Blocks: 1479935
Blocks: 1472338
See Also: → 1479956
(In reply to andreip from comment #48)
> Can this API be used from a WebExtension? I tried both in a normal web
> page's console and in the background script of a WebExtension I was
> debugging and I get "navigator.clipboard" is undefined.
> 
> Also, where is the best place to ask this sort of questions about using this
> API, I'm guessing Bugzilla is not a good place for this.

This API is currently behind a pref, so it will not be visible in either WebExtension or content contexts.
Flags: needinfo?(nika)
Is there a timeframe planned for enabling this by default? I was not able to find a bug tracking that.
Flags: needinfo?(nika)
Hi Eric! On july 31st I linked this bug to a bug for enabling the clipboard APIs by default - bug 1479935. 

I have also sent out a message to dev-platform stating that I will be enabling clipboard APIs by default - see the discussion here https://groups.google.com/forum/#!msg/mozilla.dev.platform/ef7O7PrmNh0/JfkzXZHmCQAJ;context-place=forum/mozilla.dev.platform

Hope this helps!
I have some more questions for :annyG and nika (also asked in IRC but this may be easier, I'll take an answer where I can get it).

First, the text of the information annyG previously gave me in #content on IRC:

>  sheppy: currently clipboard.writeText is available to secure contexts and web extensions (without the need to require permissions) - it is available under the same conditions as document.execCommand("copy"), and clipboard.readText is available to web extensions only. currently there is no way to expose clipboard.readText to web content. I am also cc'ing nika: for help with this question and perhaps elaboration of future plans

My questions:

1. This text specifically says that writeText() (I assume that write() and read() both follow the same rules as writeText() and readText()) does not require permissions. Does that apply to readText()?

2. I'm curious if there's a reason why writeText() is available in more cases than readText().

3. Definitely would be helpful to know what if any plans we have to expand our compatibility with spec, especially for permissions, since this is likely going to be a question we get. People will want to know when they can use these methods in web content.
One more question:

4. Can navigator.clipboard.write() be used instead of the browser extension clipboard.setImageData() method? The page about that method explains how it's needed because the standard clipboard API only works for text, but that's no longer true with the async API.
Flags: needinfo?(annygakhokidze)
(For completeness, pasting Nika's response here)
> nika> sheppy-afk: writeText can be called without permissions in a user-initiated event callback, like execCommand("copy"). readText requires the clipboardRead webextension permission to use at all, and the clipboardWrite webextension permission can be used to write to the clipboard outside of user-initiated callbacks.
> nika> sheppy-afk: you cannot read from the clipboard from web content currently.

Regarding your questions,
>1. This text specifically says that writeText() (I assume that write() and read() both follow the same rules as writeText() and readText()) does not require permissions. Does that apply to readText()?
I believe Nika has answered that above.

>2. I'm curious if there's a reason why writeText() is available in more cases than readText().
IIRC, it is because letting web content write to user's clipboard is less dangerous than letting it read user's clipboard without permission inside of the user-initiated event callback.

>3. Definitely would be helpful to know what if any plans we have to expand our compatibility with spec, especially for permissions, since this is likely going to be a question we get. People will want to know when they can use these methods in web content.
I am not sure about the plans. Nika, help? :) Should I start working on this? Or there more discussion that needs to happen before allowing this?

>4. Can navigator.clipboard.write() be used instead of the browser extension clipboard.setImageData() method? The page about that method explains how it's needed because the standard clipboard API only works for text, but that's no longer true with the async API.
clipboard.write() and clipboard.read() are currently hidden prefs. As of this moment they don't support non-text data. We held off implementing this because Nika mentioned there were still some parts of the specifications for those APIs that needed more discussion.
Flags: needinfo?(annygakhokidze)
Flags: needinfo?(nika)
Commit pushed to master at https://github.com/mdn/kumascript

https://github.com/mdn/kumascript/commit/576548007f24015ba0803c7087389fb7d9afc65a
Bug1461465 Async Clipboard updates (#780)

* Bug 1451456 - Update GroupData for Async Clipboard API
Add Navigator.clipboard, the Clipboard interface, the
clipboardchange event, and the ClipboardPermissionDescriptor
dictionary.

* Bug 1461465 - Add Clipboard interface to InterfaceData.json
I think the permissions should be clipboardWrite and clipboardRead not clipboard-write and clipboard-read. https://developer.mozilla.org/en-US/docs/Web/API/Navigator/clipboard
Flags: needinfo?(eshepherd)

This is only available in extension.

Chrome supports this in normal web page and supports both text and image (Image support will come at the end of this month):
https://bugs.chromium.org/p/chromium/issues/detail?id=150835#c113

Would you please make it available in normal web pages too?

Thanks.

Blocks: 1619251
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: