The big question here will be if we can programmatically trigger a "copy" event without incurring the pain of a security prompt (as IE has always done, and this spec is based on IE's DHTML Clipboard). It looks like a "no", at the moment:

Synthetic cut and copy events must not modify data on the system clipboard.

Something like a once-per-site security prompt (a la geolocation permissions, etc.) would fit nicely here, I think, but is not yet a part of the spec.

P.S. As for manipulating the clipboard data to be injected, I believe the spec would make that part easily achievable with something like the following code (which may not be quite right yet):

(function() {

  var textMsg = 'ZeroClipboard injected this into your system clipboard!';
  var htmlMsg = '<b>ZeroClipboard</b> injected <i>this</i> into your system clipboard!';

  var preventDefault = function(e) {
    if (typeof e.preventDefault === 'function') {
      e.preventDefault();
    }
    else {
      e.returnValue = false;
    }
  };

  var copyCallback = function(e) {
    e = e || window.event;

    if (e.clipboardData) {
      e.clipboardData.clearData();
      e.clipboardData.setData('text/plain', textMsg);
      e.clipboardData.setData('text/html', htmlMsg);
      // Wacky: Must prevent default in order to get this copied into the clipboard
      preventDefault(e);
    }
    else if (window.clipboardData) {
      window.clipboardData.clearData();
      // Only supports plain text and URLs, not HTML
      window.clipboardData.setData('text', textMsg);
      // Wacky: Must prevent default in order to get this copied into the clipboard
      preventDefault(e);
    }
    // else don't preventDefault
  };

  if (typeof document.addEventListener === 'function') {
    document.addEventListener('copy', copyCallback, false);
  }
  else if (typeof document.attachEvent === 'function') {
    document.attachEvent('oncopy', copyCallback);
  }

})();

Extrapolated from the new spec and this old Microsoft example.

Just posted a message to the HTML5 Clipboard API (webapps) mailing list about this idea.

Something like a once-per-site security prompt (a la geolocation permissions, etc.) would fit nicely here, I think, but is not yet a part of the spec.

Archived version is here: http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0061.html

Tangent: This isn't actually helpful to us but I found it pretty interesting.

Trello uses a clever mechanism to alter the contents going into the clipboard without using the HTML5 Clipboard API. Only major drawback is that it requires the user to trigger a keyboard-based copy (i.e. Ctrl+C).

Success! There is now a W3C bug to make this possible in the HTML5 Clipboard API: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235

The editor's draft of the spec has been updated to support this: http://dev.w3.org/2006/webapi/clipops/clipops.html

However:

1. There still isn't any way to feature-detect this capability
2. No browsers have implemented this semi-trusted privilege for copy/cut yet

this is also a good alternative:
http://stackoverflow.com/questions/10729570/html5-alternative-to-flash-based-zeroclipboard-for-safe-copying-of-data-to-clipb

function copyToClipboard (text) {
     window.prompt ("Copy to clipboard: Ctrl+C, Enter", text);
 }

Chrome Launch Issue: https://code.google.com/p/chromium/issues/detail?id=437908

Thanks for the link, @codylerum!

The biggest problem is still that inability to feature detect Clipboard API support, which makes determining the need for Flash awkwardly late (the first click would potentially be wasted by trying to detect if the Clipboard API is supported). 😢

When the HTML Clipboard API is discoverable and usable in 1+ browsers, we should revisit any issues that have the "HTML TopLayer" label assigned.

Landed in Chrome 43:
https://code.google.com/p/chromium/issues/detail?id=437908#c8
http://updates.html5rocks.com/2015/04/cut-and-copy-commands

Here's what github does to enable copy to clipboard without flash. It's based on useragent sniffing and not feature detection, which is why it's not in ZC yet. https://gist.github.com/jonrohan/81085b119d16cdd7868a

Thanks, @jonrohan!

Just want to note that if we did the browser sniffing (like Github's implementation) then in about 50 lines of code this would be done by now and actually 100% reliable in this case. Saying that with wholehearted respect for feature-detection which I do hope will work.

@groovenectar well, in this case we have feature detection in approx two lines of code and we haven't yet found a browser where it's not reliable.

(Regarding time taken - to begin with I underestimated the complexity of the whole project and thought it would be easy to split the whole thing into two separate scripts - one for Flash and one for native. It would certainly be sweet to ensure browsers with native support didn't have to load and parse all the Flash-related code, right? Turns out it wasn't so simple and once I started testing pages with several ZC instances requiring different behaviours I realised my first approach was a bad idea and started over. If you think you have a better approach just code it and send a competing pull request, the more the merrier.)

BTW - here's the fix for the "emits Flash errors even if it intends to use native API" bug: 26a3aa6
Thanks, @peteallen .

FYI: Safari 10 supports execCommand('copy') and disables Flash by default.
https://developer.apple.com/library/prerelease/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_10_0.html
https://webkit.org/blog/6589/next-steps-for-legacy-plug-ins/

Can we get this committed?

I think it's pretty ready to be committed - but I'm afraid it's flagged as decreasing test coverage somewhat. I'm not entirely sure how to fix that (and I no longer work for the employee who was funding this stuff so far, so I'll have less time available to figure things out..).

Maybe @JamesMGreene has thoughts on fixing the test coverage..

Is there anything specific that needs more testing now?

Chrome is blocking Flash now, please merge this.

Is there any news on the progress of this?

I'm not sure what the issue is currently, but could throw this in there to get it working quickly and reliably:

#171 (comment)

It would return an id of the browser if there's any need to know it, or false if the browser doesn't support native clipboard... I used this on the application side to determine whether to inject ZeroClipboard or use native and it worked well

State: The PR #650 is readyish - I just merged in master and fixed some conflicts a few weeks ago but apparently later changes on master caused some more conflicts that need resolving..

Just so everyone is clear on the state of things here, as I know everyone is dying to get this long overdue feature: I have 1 more bug (#533) that I'd like to fix before releasing 2.3.0, though I will bump the bug into a later release if I can't hammer it out in the next 2-3 days. After 2.3.0 goes out, I intend to immediately deal with @hallvors's PR #650 and get this feature (and only this feature) released in 2.4.0 ASAP. Thanks for all your patience! ❤️

@JamesMGreene is there a path forward for this? I'm not meaning to be impatient, just curious what the direction is of this feature as of April.

Hi guys. I found this page via Google search looking for a way to feature detect W3C Clipboard API support in the browser. Have you found a solution for this?

@krisztianb, I recommend checking out the clipboard.js library.