Re: [clipboard events] click-to-copy support could be hasFeature discoverable?

> hasFeature() is pretty much killed (always returns true).

That sort of sucks .. I know the argument against it but the question I'm looking at now shows that not all features are suitable for feature detection - in this particular case because the whole point of the feature is about user interaction, and without user interaction you can't detect it.

Is the "always returns true" part also widely implemented now? If the default were "false" it could still be useful in odd cases like this one.

> Why can't this feature be discovered? The clipboard cannot be made
> readable when you just copied to it using this technique?

Hm.. How would that work? You would end up with something like this:

button.onclick = function(){
    button.dispatchEvent(new ClipboardEvent('copy', {dataType:'text/plain', data:'Hello world'});
    // did that succeed or not? We don't have event.clipboardData on a clip event object
    button.addEventListener('paste', function(e){
        if(e.clipboardData.getData('text/plain') !== 'Hello world'){
            makeFlashFallbackButton();
            alert('Sorry, copy failed - please click the button again');
        }
        button.removeEventListener('paste', arguments.callee, false);
    }, false);
    button.dispatchEvent(new ClipboardEvent('paste'));
}

and you'd still have issues because 
1) Synthetic paste events are not covered by click-to- logic, but by a real preference the user must toggle. And no, you can't discover if the preference is set, and that's by design. Isn't it totally weird even for users who have some understanding of what's going on if the UA pops up a "do you want to allow paste" dialog when you try to click a button to copy something?
2) The UI for copy/cut would  totally suck with this approach - "Sorry, first time you clicked the copy button it failed - please click it again"..?
3) You might have both false positives (the data on the clipboard just happened to be the same string you tried to copy) and false negatives (another app happened to overwrite the clipboard between your copy event and your paste event). Granted both are extreme corner cases..

It's almost more elegant to add a dedicated discoverability property on the ClipboardEvent constructor. 
if(window.ClipboardEvent && ClipboardEvent.clickToCutAndCopyEnabled)
but it's not exactly beautiful and there's no precedence for this in the platform AFAIK.

Any better idea?
-Hallvord

Received on Monday, 19 May 2014 19:21:51 UTC