W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: clipboard events

From: timeless <timeless@gmail.com>
Date: Tue, 10 May 2011 10:41:38 +0300
Message-ID: <BANLkTi=mipN8MZYJ-P4_Lvz2od6LWQjG-g@mail.gmail.com>
To: Daniel Cheng <dcheng@chromium.org>, Paul Libbrecht <paul@hoplahup.net>, João Eiras <joao.eiras@gmail.com>, public-webapps@w3.org
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 -

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:19 UTC