Re: clipboard events

I'm not really excited by the return of the attack on context menus.
Allowing web sites to hold user's browsers hostage is a bad starting
point. It might be ok if the user had to first opt into rich editing -
maybe.

Note that we only recently added protection for users against 'what
you see is not what you copy' (serializers are now fairly css aware).

On 5/10/11, Daniel Cheng <dcheng@chromium.org> wrote:
> 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
>

-- 
Sent from my mobile device

Received on Tuesday, 10 May 2011 07:42:08 UTC