Re: on execCommand() and script-triggered copy/cut/paste

On Tue, Aug 4, 2015 at 5:06 PM, Johannes Wilm <>

> But now that I found out that y'all are doing precisely that, I found it
> was necessary to put a warning in the spec documents saying that this spec
> is likely going to be deprecated, so that noone gets the idea to build new
> features based on it.
> At the F2F we probably come up with a better wording that is more precise.

I think "deprecated" is the right word for the goal you're describing, I'm
just saying the goal itself is unrealistic and therefore pointless.

If I may quote Aryeh Gregor himself (I hope he doesn't mind..)
"it's true execCommand etc. will probably never be removable"  - from

> (Your spec is (obviously) at an early stage - for example it describes a
>> deleteContent intention but doesn't explain how to pass the direction of
>> the delete action to the JS listener.)
> Not true -- there are both deleteContentForward and deleteContentBackward
> that make that very clear.

Oh sorry, I must have missed them, but I was reading where these are
not mentioned.

> We are currently trying to make sure that the first version of these specs
> will be able to handle everything we need to do in today's leading JS
> editors.

(I'm still worried you're simply moving the complexity of implementing
editing well from the UA implementors to the JS authors. Probably a natural
impulse since the UAs have done a poor job.)

> So that leaves "copy". As I understand your security model, you allow
> execCommand('copy') to add any text or HTML content to the clipboard even
> if this text is invisible to the user, as long as the execCommand was
>  called as part of a function that was called due to user action (such as
> clicking on a button).
> So if you want the browser to copy some content that the user is not to
> see, you can simply create a contentEditable=true element, fill it with the
> content to copy, select that content, call execCommand('copy'), then remove
> the contentEditable=true from the DOM. See this example:

You don't need those DOM modifications - just listening to the 'copy' event
the execCommand() call triggers and call event.clipboardData.setData() or

It is a bit hackish though..

> That is then needlessly complicated for no good reason. Instead, it should
> just be enough to have a function such as document.addToClipboard(content)
> that can take text/html as it's argument and that has a security check that
> only allows the execution of this function if it ultimately has been
> initialized due to user interaction.
> However, I can see that we may end up with a few more such functions in
> the future document.pasteFromClipboard(), etc., some of which we cannot
> even think of now. So in that case it may actually be a good idea to have a
> generic interface, similar to execCommand(X), just with a different name.
> The different name is important so that it will be easier to remove
> execCommand in the future.

Why is it so important to remove document.execCommand() - rather than just
saying "it's not possible to use most commands for contenteditable=intents


Received on Tuesday, 4 August 2015 21:07:13 UTC