Re: [clipboard events] implicitly prevent default event action?

On Tue, May 20, 2014 at 3:42 AM, Hallvord R. M. Steen <hsteen@mozilla.com>wrote:

> >> a) The event is script-generated and has a data payload (new
> >> ClipboardEvent('copy', {dataType:'text/plain', data:'Hi World'}))
>
> > I'm a little confused.  Script-generated events never have a "default
> > action", except for a couple isolated web-compatibility hacks where
> > dispatching an event in script has side-effects, like click.
>
> Hm.. I didn't really know that was a "rule". I basically want
>

I think two reasons people get confused over this are the use of the term
"default action", which makes it sound like the "action" is part of
dispatching the event, and that there are a couple events which break this
rule (onclick; I think there are one or two others).  Reading
http://dom.spec.whatwg.org/#dispatching-events helps make this clear--it
never talks about a "default action", it just tells the caller if
preventDefault() was called.

Anne: Something else that might help is speccing how the weird click-like
events work.  Those really do need a "default action" (though it should
probably be called something else, too much confusion over that phrase),
and there could be a big bold "for web-compatibility use only" warning next
to it.  I don't know if it'll help, but it seems like the event model needs
a hook for this anyway.


> > Is there any way for the .clipboardData object to get reused (eg. where
> the
> > .changed flag would be set to true from a previous event)?
>
> Well, I guess it's always possible to have an event listener call
> dispatchEvent() on some other element, passing the same event object.. Not
> sure if that matters?
>

As long as the "implicit default behavior" is removed this will have no
effect, since the only place this flag would be checked is after a real
event dispatch.

Checking whether the DataTransfer has data in it could work, too.  I
assumed that it would be pre-filled with the user's selection, and calling
setData() would just replace it.  By the way, what's the reason for not
doing it that way?  It seems to make everything simpler: it's always the
contents of .clipboardData that's being copied, .clipboardData is initially
set to the selection (resulting in no change to behavior if you don't touch
.clipboardData), and you never have to preventDefault() to change what's
copied.  I guess it assumes that any selection that the UA can support for
copy can be represented in DataTransfer, but that seems like it could be
dealt with (not every detail of the selection necessarily needs to be
script-visible in the DataTransfer).

-- 
Glenn Maynard