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: [email protected] [mailto:[email protected]] 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 <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] 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 <[email protected]<mailto:[email protected]>> 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
