W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events

From: Aryeh Gregor <ayg@aryeh.name>
Date: Wed, 2 May 2012 09:23:31 +0300
Message-ID: <CAKA+Ax=nR7v4ywtf7zJsO-3sctN8CnOtP5hkg=RTptaP7BeOYw@mail.gmail.com>
To: Ryosuke Niwa <rniwa@webkit.org>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Scott González <scott.gonzalez@gmail.com>, public-webapps <public-webapps@w3.org>
On Wed, May 2, 2012 at 9:04 AM, Ryosuke Niwa <rniwa@webkit.org> wrote:
> That's a good point. What would be a viable alternative then?

The use-case is "disable cut/copy/paste and also hide those options
from context menus", right?

I think these are two separate features.  First, you want to prevent
the action from showing in the context menu.  Second, you want to
prevent it from occurring.  These shouldn't be conflated, because 1)
users can cut/copy/paste without using the context menu, and 2) maybe
when they opened the context menu you wanted to allow the
cut/copy/paste but when they click the option something has changed
and you no longer want to allow it, or vice versa.

So I think we should have two separate sets of events: one type of
event that fires when cut/copy/paste options would appear in a context
menu, and one that fires when the cut/copy/paste is actually
attempted, both sets cancelable.

For the former, I'd suggest onbeforecontextmenu, with some way to
disable specific options, like extra boolean parameters (or a
dictionary) on the event.  So you'd do something like
addEventListener("beforecontextmenu", function(e) { if (foo()) {
e.enabledOptions.cut = e.enabledOptions.copy = false }}).

The logical name for the latter is
onbeforecut/onbeforecopy/onbeforepaste, but those are taken.  :(  Can
we maybe repurpose them anyway?

(Aside: does it really make sense to fire separate events for cut and
copy?  cut is equivalent to copy followed by delete, so it would make
sense for it to fire events like that.  This way, oncopy handlers will
fire for cut too, which is almost surely what's wanted.  And if we
support some type of ondelete or onbeforedelete event, they should
fire for cut too.  This means separate events probably aren't needed.
But they should be treated separately for onbeforecontextmenu, if we
have such an event.)
Received on Wednesday, 2 May 2012 06:24:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:33 UTC