This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
Also: do we need to consider adding Touch and Pointer events to this whitelist, e.g. `tap`, `pointerdown`, etc.?
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)
http://dev.w3.org/2006/webapi/clipops/clipops.html#semi-trusted-event
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.
> 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.
> 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
> 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
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?
(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.
That's more inline with what I had in mind. It would definitely work for my needs.
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
(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
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?
(I would assume so but our Gists in this thread haven't done so.)
(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).
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.
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.