Re: clipboard events

On Mon, May 9, 2011 at 23:31, Paul Libbrecht <paul@hoplahup.net> wrote:

>
> Le 10 mai 2011 à 00:18, João Eiras a écrit :
>
> >> I would just model the 'copy' (and 'cut') events exactly as a
> 'dragstart'
> >> event, ideally so much so that you can literally use the same function
> for
> >> both. (Canceling 'cut' would prevent the default deletion of the
> >> selection, canceling 'copy' has no effect.)
> >
> > Shouldn't canceling 'copy' prevent the data from being placed in the
> clipboard ?
>
> I am not sure of the above. I feel it should either be:
> A- this (stop the copy, triggering an error)
> B- or remove all of the script's modifications of the clipboard data and
> leaves it to the "native copy"
>
> The advantage with B is that it prevents scripts that would try to prevent
> a copy which is important I feel.
>
> > That way a script can instead explicitly set the contents of the
> clipboard, if some sanitization needs to be done.
>
> I do not think this should be possible since writing to clipboard should
> only be doable with a copy event triggered by the environment (typically at
> the invocation of the standard gesture).
>
> paul
>

I would expect scripts to want one of two things when they're preventing the
default action:
1. They want to set their own data in the clipboard instead of what the
browser would normally provide by default--for example, a document editor
that does its own layout instead of using contenteditable.
2. They don't want to allow someone to copy data--perhaps it's data on a
sensitive page.

I think it's important to enable both.

Originally, I wanted to rewrite the copy/cut events to work like this in
WebKit:
1. Fire a copy event at the DOM.
2. If the default action was cancelled and event.clipboardData was not
mutated, simply return without doing anything.
3. If the default action was cancelled and event.clipboardData was mutated,
replace the contents of the system clipboard with the contents of
event.clipboardData.
4. Otherwise, if the default action is not cancelled, proceed with the
default clipboard population behavior.

I'm not sure if a 'dirty' bit on clipboardData is a great signal to use
though.

Daniel