On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen <hallv...@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<http://msdn.microsoft.com/en-us/library/ms536901(VS.85).aspx>
> [2] http://samples.msdn.microsoft.**com/workshop/samples/author/**
> dhtml/refs/onbeforecopyEX.htm<http://samples.msdn.microsoft.com/workshop/samples/author/dhtml/refs/onbeforecopyEX.htm>
>
>
>
