beforecut/copy/paste events ( Re: some questions regarding clipboard event / clipboard data API)

On Sat, 18 Sep 2010 05:59:00 +0900, Tony Chang <tony@chromium.org> wrote:
> On Fri, Sep 17, 2010 at 5:47 AM, Hallvord R. M. Steen  
> <hallvord@opera.com>wrote:
> 4) Although both IE and WebKit support before* events (beforecut,
>> beforecopy, beforepaste) I've omitted them because I can't see the use
>> case for these events. What distinguishes a before* event from a
>> regular cut/copy/paste event? Why is it useful to have both? Are you
>> aware of legacy content that requires before* events?
>
> I had thought preventDefault() only worked in the before events, but that
> doesn't seem to be the case.  Sorry, I can't seem to remember the
> difference, but maybe Ojan does.

I noticed this blog post:
http://almaer.com/blog/supporting-the-system-clipboard-in-your-web-applications-what-a-pain
Giving an actual use case for before* events: controlling the "disabled"  
state of cut/copy/paste entries in a menu.

While this is useful and a good reason to support before(cut|copy|paste),  
adding these as ClipboardEvents makes the security model in the draft I'm  
spec'ing somewhat more shaky. I don't see any problems with allowing  
event.clipboardData.getData() from a paste handler - the user is  
presumably consciously triggering a paste, so we should give the script  
whatever we have. On the other hand, a before* event might fire just  
because the user opened the context menu or Edit menu.. That in itself  
certainly doesn't indicate any intention to share clipboard data with the  
page.

In short: I'd like to support before* events, but consider making them  
UIEvents or just Events rather than use the ClipboardEvents interface with  
event.clipboardData.

> Before showing the user a menu with a disabled cut entry, the 
> implementation should fire a beforecut event to let the script
> control the disabled state of the command.
> The default action of the beforecut event is to disable the
> corresponding menu entry if there is no selection.

IE and WebKit fire before* a lot more often that that - they also fire a  
beforecopy before the actual copy when you press Ctrl-C and so on. I  
really don't see any use case for that, especially if we drop the  
ClipboardEvents interface for the before* events..

This functionality is still too limited to cover all use cases. For  
example, one might want an application that handled beforepaste when the  
cursor was inside an editable element, determined by examining the  
event.clipboardData.types that the type(s) of content available on the  
clipboard were not suitable for pasting in the current location, and  
disabled the paste entry.

The big question is of course whether we would get away with making  
before* events use the Event interface compatibility-wise. Opinions and  
experience here most welcome!

-- 
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

Received on Monday, 1 November 2010 03:43:24 UTC