Patrick Kettner offered up another idea for this as well on a related
Modernizr issue [1]:

Given the following
>    1. we must not change the user's clipboard
>    2. we must use a synthetic event
>    3. synthetic event be able to actually work (clipboard poisoning, etc)
> is there any chance that a synthetic clipboard copy/paste could throw a
> unique err[or] that we could try/catch around and sniff for?

Ryan Seddon affirmed this idea in his response [2]:

That's a great idea, if we try to poison the clipboard with a synthetic
> copy event it should probably throw an UNSTRUSTED error or something
> along those lines.

What do others think of that approach?

I'm fine with it, and I'm guessing it would be easier for both browser
vendors and consumers to implement than other previously discussed


    James Greene

On Mon, Apr 20, 2015 at 5:09 PM, Hallvord Reiar Michaelsen Steen <> wrote:

> On Wed, Feb 11, 2015 at 7:21 PM, James M. Greene <
> > wrote:
>> The current spec still leaves me a bit unclear about if implementors must
>> include the ability to feature detect Clipboard API support, which I think
>> is a critical requirement.
> I agree it's a very important requirement. And it sucks that we're still
> struggling to find a good story..
> Here's one (semi-random) idea: the interaction with APIs like
> queryCommandEnabled() isn't really fleshed out yet. What if we mandate in
> the spec that calling queryCommandEnabled must fire the corresponding
> onbefore* event synchronously, and also recommend that this is only
> implemented when the support for the other parts is ready to go?
> The feature detection might then look a bit like this:
> var modernClipboardImplementation = false;
> document.onbeforecut = function(e){
>     e.preventDefault();
> }
> try{
>     if(document.queryCommandEnabled('cut')){
>         modernClipboardImplementation = true;
>     }
> }catch(e){
>         modernClipboardImplementation = false; // yeah, likely not
> necessary..
> }
> In other words: if the onbeforecut fires and you can prevent the default
> action to tell the script using queryCommandEnabled() that cut is enabled,
> we assume the implementation is top-notch. It probably includes
> click-to-copy too.. ;)
> Maybe not super-elegant, but not too convoluted either - and no
> implementation I've tested so far does it.
> -Hallvord

Reply via email to