Re: clipboard events

The alternative is sites that attempt to implement this functionality by
preventing the default and clearing all the data on the clipboard instead.
I'm not really sure that's any better.

Daniel

On Tue, May 10, 2011 at 00:41, timeless <timeless@gmail.com> wrote:

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