RE: [Clipboard API] The before* events

>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.

From: 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