Bug 23235 - (click-to-copy) allow triggering copy action from certain event handlers
(click-to-copy)
allow triggering copy action from certain event handlers
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: Clipboard API and events
unspecified
All All
: P1 major
: ---
Assigned To: Hallvord R. M. Steen
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-13 09:08 UTC by Hallvord R. M. Steen
Modified: 2014-01-29 22:35 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hallvord R. M. Steen 2013-09-13 09:08:46 UTC
Per discussion at http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0061.html and onwards, we should allow script treads triggered from a white-list of trusted events to use document.execCommand('copy|cut|paste').

(White-listing is required to avoid allowing reading clipboard data from mousemove and similar events.)

Suggested white-list:
 keydown
 keypress
 keyup
 click
 dblclick

This presumably gives us feature parity with the Flash player.

Trust settings or similar configuration should be available to override this requirement and enable event-less polling of or writing to the clipboard, but this is up to UAs.

(The security policy might also choose to distinguish the more dangerous document.execCommand('paste') from the others. Preventing copy/cut are more about avoiding nuisance, while preventing paste is an essential privacy measure. At the time of writing, I don't remember how implementations currently do this.)

Finally, for obvious reasons this bug may have to be fixed in an editing API spec, not in Clipboard Events.
Comment 1 James M. Greene 2013-09-13 15:57:05 UTC
Just to be clear: I was only asking for click-to-copy.  I feel that cut and paste are much different operations that already have good models around them.

For example, click-to-cut would really only make sense within a "contenteditable" element or a form field element (e.g. `input[type=text]` or `textarea`).  I believe that the "contenteditable" elements can already call `document.execCommand("cut");` today (right?). And having a "cut" button/link for a plain `textarea` seems like overkill.

As mentioned in Hallvord's original description, "paste" is a dangerous operation to allow any additional access to.  I don't see any need to enable click-to-paste.  I think being allowed to read the data only when the user explicitly pastes into some element on the page makes perfect sense, and the current spec already allows that.
Comment 2 James M. Greene 2014-01-16 17:36:43 UTC
Also: do we need to consider adding Touch and Pointer events to this whitelist, e.g. `tap`, `pointerdown`, etc.?
Comment 3 Hallvord R. M. Steen 2014-01-21 00:03:55 UTC
I seems inconsistent to allow only copy and not cut, the privacy/security/nuisance considerantions are exactly the same. The plan is to allow click-to-copy and click-to-cut (while in the names of inconsistency and privacy require that the implementation is configured to allow scripted paste for the click-to-paste feature)
Comment 5 James M. Greene 2014-01-23 23:29:37 UTC
I'm absolutely ecstatic over this one. Now, of course, I must wait for the various browser vendors to start updating/adding their clipboard APIs. :)

Also, just so I'm clear: this bug originally started by discussing using `document.execCommand` to execute copy/cut but the spec update would suggest (to me) that developers would be able to dispatch a "beforecopy"/"copy"/"beforecut"/"cut" event using the normal event dispatching mechanisms (i.e. `EventTarget#dispatchEvent`).  Is that accurate?  I do actually prefer that style over the sometimes sketchy `execCommand` API.
Comment 6 Hallvord R. M. Steen 2014-01-23 23:44:41 UTC
> do we need to consider adding Touch and Pointer events

(Never really responded to this one..) The spec leaves this open in a (somewhat) hand-wavy manner, saying that implementations should consider all events it thinks expresses user intention or something like that. That may not be ideal, given that it opens the door to implementation fragmentation, on the other hand with the possibility for yet other input modes and events in the future it's better to leave things slightly underdefined here I think.

(In reply to James M. Greene from comment #5)
> Also, just so I'm clear: this bug originally started by discussing using
> `document.execCommand` to execute copy/cut but the spec update would suggest
> (to me) that developers would be able to dispatch a
> "beforecopy"/"copy"/"beforecut"/"cut" event using the normal event
> dispatching mechanisms (i.e. `EventTarget#dispatchEvent`). 

Don't worry about the before* events, they wouldn't be useful in a script-triggered context anyway :-). Apart from that: yes, this is correct. The event API gives you some more power - i.e. if you just want to trigger a copy of the selected text without further ado you can use execCommand(), if you want to copy some specific text/data that your script already knows you can dispatch an event with data and dataType set, and you no longer need the quirky "dispatch-event-then-run-event-listener-modify-data" hack that the previous versions of the spec required.
Comment 7 James M. Greene 2014-01-23 23:57:54 UTC
> if you want to copy some specific text/data that your script already knows you
> can dispatch an event with data and dataType set, and you no longer need the
> quirky "dispatch-event-then-run-event-listener-modify-data" hack that the
> previous versions of the spec required.

I'm unsure what that means. I thought the new changes implied utilizing it like the following Gist demonstrates but your wording would suggest that this is overkill: https://gist.github.com/JamesMGreene/8589353
Comment 8 Hallvord R. M. Steen 2014-01-24 00:21:27 UTC
> https://gist.github.com/JamesMGreene/8589353

Yes, per the newest iteration of the spec this should be all you need:
https://gist.github.com/hallvors/8589631
Comment 9 James M. Greene 2014-01-24 00:58:50 UTC
How would you do a simulated event with multiple data types, though? If I dispatched multiple `ClipboardEvent`s, each subsequent event would implicitly be calling `clearData()` and thus nullifying the effects of previous events, right?
Comment 10 Hallvord R. M. Steen 2014-01-24 01:35:25 UTC
(In reply to James M. Greene from comment #9)
> How would you do a simulated event with multiple data types, though?

That's indeed not handled at the moment. I've been considering saying that the implementation must automatically create a text/plain form if scripts set text/html only, but that's just one use case. Dispatching multiple events isn't the way to go either. Potentially, one could imagine syntaxes like

new ClipboardEvent('copy', {data:{'text/plain':'test', 'text/html':'<p>test</p>'}}

I'm not sure if that's the best way.
Comment 11 James M. Greene 2014-01-24 03:01:54 UTC
That's more inline with what I had in mind. It would definitely work for my needs.
Comment 12 James M. Greene 2014-01-24 14:09:01 UTC
Maybe we're over-thinking this... we don't really need any constructor overloads at all... we really just need to be able to invoke `setData` on the `ClipboardEvent` during a semi-trusted event flow:
   https://gist.github.com/JamesMGreene/8597596
Comment 13 Hallvord R. M. Steen 2014-01-24 14:23:13 UTC
(In reply to James M. Greene from comment #12)
> Maybe we're over-thinking this... we don't really need any constructor
> overloads at all... we really just need to be able to invoke `setData` on
> the `ClipboardEvent` during a semi-trusted event flow:
>    https://gist.github.com/JamesMGreene/8597596

That's already possible - good point :-). I'll keep data/dataType but your use case is covered after all :-D
Comment 14 James M. Greene 2014-01-24 14:54:25 UTC
Do we need to call `e.preventDefault();` on the simulated `ClipboardEvent` in order to actually get the data into the system/desktop clipboard like we do in a normal `copy` event listener/handler?
Comment 15 James M. Greene 2014-01-24 15:04:54 UTC
(I would assume so but our Gists in this thread haven't done so.)
Comment 16 Hallvord R. M. Steen 2014-01-25 11:50:10 UTC
(In reply to James M. Greene from comment #15)
> (I would assume so but our Gists in this thread haven't done so.)

Oh, we do  indeed. (Hate that gotcha).
Comment 17 James M. Greene 2014-01-27 14:38:38 UTC
Yeah, that is a very annoying gotcha. I understand WHY it's necessary and that we are keeping it for backward compatibility's sake but, still... ugh.

Anyway, I've updated my Gists and left a comment on your forked Gist in case someone happens upon them through this bug in the future.
Comment 18 James M. Greene 2014-01-29 22:35:39 UTC
One more very important question: how would I be able to detect if a browser supports these semi-trusted `ClipboardEvent`s so I can gracefully degrade if necessary?

Apologies if I missed it.