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

On Tue, Aug 4, 2015 at 11:06 PM, Hallvord Reiar Michaelsen Steen <
hsteen@mozilla.com> wrote:

> On Tue, Aug 4, 2015 at 5:06 PM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
>> 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
> https://github.com/w3c/clipboard-apis/issues/16#issuecomment-127568051
>

That sounds like a defeatist attitude. In that case I think the word
"deprecated" is correct. Not everything that is marked as "deprecated"
disappears quite as fast as those deprecating it had hoped for. Sometimes
things are even "un-deprecated". But to give up before one even begins
doesn't sound like a healthy attitude.

Also, I do not think that people in 200 years time will keep execCommand
around because someone wrote a webpage in 2007 using it and refuses to
change it now.


>
>
>
>>
>> (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
> http://w3c.github.io/editing/contentEditableIntentions.html where these
> are not mentioned.
>

Ah, I see. Yes that needs to be changed there. The current list of
intentions is in this spec:

https://w3c.github.io/editing/input-events.html

But what is missing there are intentions related to the clipboard
(paste/copy/cut) as we had thought we could work with those defined in the
clipoboard api. But let us know if you think we should create them here
separately.


>
>
>> 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.)
>

Yes, the very first step is about giving access to the primitives necessary
to create an editor on top in JS. Already today most JS editors have to
reimplement most of the logic as browsers are so inconsistent and broken.

But the idea is for this to only be the first module in a series of
modules. Once we have this, and have some implementations of it, building
on top of the principles laid down in the Extensible Web Manifesto
https://extensiblewebmanifesto.org/ it should be much easier to create
specs for particular sub areas (typing, paragraph splitting, caret
movement, etc.) by JS polyfilling and testing on real users.


>
>
>
>
>> 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:
>> http://pastebin.com/fnVGa7wC
>>
>
> You don't need those DOM modifications - just listening to the 'copy'
> event the execCommand() call triggers and call
> event.clipboardData.setData() or event.clipboardData.items.add().
>
>
I tried doing the same without adding the contentEditable attribute, and it
wouldn't work. Am I missing somethign here?


> It is a bit hackish though..
>
>

Right, so let's not start doing hackish things.


> 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
> elements"?
>


To have a clean break from a broken past. And also to make the web less
hackish. If I understand you correctly, and Chrome is currently behaving
correctly in terms of security, the rule is that: We allow the browser to
put arbitrary content into the clipboard, as long as:

A) the script that does it is directly triggered by the end user
B) the script is willing to go through some loops by creating a
contenteditable element, putting the contents in there, copying it, and
removing the contenteditable element again.


A makes sense, but B just seems nonsensical. Anyone wanting to put "bad"
content onto the clipboard will easily be able to do it, whereas anyone
else who just wants to put legitimate content into the clipboard will have
to jump through a meaningless series of  DOM changes.


If I understand you correctly, you want us to use execCommand just for the
single case that one wants to create an extra UI button for copying.
Buttons for pasting will not work anyway, and the cut button would in the
end also call the same execCommand('copy',...)


I don't think it's worth it to keep execCommand around for that.

But possibly we could have a function to declare an intention. Such as
cEelement.execIntention('copy') or cEelement.execIntention('paste').

That could possibly be used then to also declare other intentions by custom
UI buttons.

Alternatively y'all put something similar into your clipboard api.

-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org