Re: [Clipboard API] The before* events

On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead <
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] *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>
> 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
>
> ****
>
>  ** **
>