RE: [Clipboard API] The before* events

You are right, that it doesn't solve the "disabling the option in the browser chrome" case-but is that really necessary? Why would a site want to do this?

The only reason I can imagine is the old "we want to prevent the casual user from copying this image because it is copyrighted" scenario. In the cut/paste interaction, there are other ways to handle this such as making the control read-only, or stoping the action at the keyboard event level.

IE10 (and other UAs) have another solution-allow more fine-grained control over the management of selection (css property<http://msdn.microsoft.com/en-us/library/ie/hh781492(v=vs.85).aspx>, and example usage<http://ie.microsoft.com/testdrive/HTML5/msUserSelect/>). I can imagine a similar model for specific control over cut/copy/paste from certain parts of the page if this is a hard requirement. The CSS property means that the developer's request can be honored by the user agent without script getting in the way of (and possibly delaying) the action.

From: ojan@google.com [mailto:ojan@google.com] On Behalf Of Ojan Vafai
Sent: Thursday, November 1, 2012 4:38 PM
To: Travis Leithead
Cc: Hallvord R. M. Steen; WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern Hoehrmann; Sebastian Markbåge
Subject: Re: [Clipboard API] The before* events

On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead <travis.leithead@microsoft.com<mailto:travis.leithead@microsoft.com>> wrote:
>I'm looking at the beforecut, beforecopy and beforepaste events. I don't entirely understand their intent, it seems even more obscure than I expected..

I'm not sure that the use case that these events were originally designed for (which have been obscured by time), are at all relevant to site content any more. The use case of hiding the cut/copy/paste menu options, can be fulfilled by replacing the contextmenu with some custom one if desired.

You don't want to disable the other items in the context menu though. This also doesn't solve disabling cut/copy/paste in non-context menus, e.g. Chrome has these in the Chrome menu.


From: ojan@google.com<mailto:ojan@google.com> [mailto:ojan@google.com<mailto:ojan@google.com>] On Behalf Of Ojan Vafai
Sent: Wednesday, October 31, 2012 10:21 PM
To: Hallvord R. M. Steen
Cc: WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern Hoehrmann; Sebastian Markbåge
Subject: Re: [Clipboard API] The before* events

On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen <hallvord@opera.com<mailto:hallvord@opera.com>> wrote:
I'm looking at the beforecut, beforecopy and beforepaste events. I don't entirely understand their intent, it seems even more obscure than I expected..

Nothing in the official MSDN documentation [1] really explains the interaction between beforecopy and copy (given that you can control the data put on the clipboard from the copy event without handling beforecopy at all, the demo labelled "this example uses the onbeforecopy event to customize copy behavior" doesn't really make sense to me either.)

I was under the impression that you could handle the before* events to control the state of copy/cut/paste UI like menu entries. However, when tweaking a local copy of the MSDN code sample [2], I don't see any difference in IE8's UI whether the event.returnValue is set to true or false in the beforecopy listener.

Another problem with using before* event to control the state of copy/cut/paste UI is that it only works for UI that is shown/hidden on demand (like menus) and not for UI that is always present (like toolbar buttons). I'm not aware of web browsers that have UI with copy/cut/paste buttons by default, but some browsers are customizable and some might have toolbar buttons for this.

I'm wondering if specifying something like

navigator.setCommandState('copy', false); // any "copy" UI is now disabled until app calls setCommandState('copy', true) or user navigates away from page

would be more usable? A site/app could call that at will depending on its internal state. Or, if we want to handle the data type stuff, we could say

navigator.setCommandState('paste', true, {types:['text/plain','text/html']});

to enable any "paste plain text" and "paste rich text" UI in the browser?

I don't have a strong opinion on the specifics of the API, but I agree that this is much more usable than the before* events. In the common case, web developers would have to listen to selectionchange/focus/blur events and call these methods appropriately.

The downside to an approach like this is that web developers can easily screw up and leave the cut/copy/paste items permanently enabled/disabled for that tab. I don't have a suggestion that avoids this though. I suppose you could have this state automatically get reset on every focus change. Then it would be on the developer to make sure to set it correctly. That's annoying in a different way though.

-Hallvord

[1] http://msdn.microsoft.com/en-us/library/ms536901(VS.85).aspx
[2] http://samples.msdn.microsoft.com/workshop/samples/author/dhtml/refs/onbeforecopyEX.htm