Re: [clipboard events] click-to-copy support could be hasFeature discoverable?

I think I'd suggest avoiding the mess of execCommand altogether, and add
new methods, eg. window.copy() and window.cut() (or maybe just one method,
with a "cut" option).  execCommand is such a nonsensical way to expose an
API that trying to stay consistent with its commands is probably not much
of a win.


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

> However, if a scripted copy event can't take a payload and have it placed
> on the clipboard, what's the point of making script-generated copy events
> possible in the first place? If there's no point I'd rather disallow them.
>

This seems like you don't like an aspect of the DOM event model, so you
want it to behave differently when used with your API.  :)  There's nothing
special about copy for it to behave differently from other events, and the
other events on the platform can be generated by script.

On Tue, May 20, 2014 at 5:48 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> How is it true for click?
>

(We clarified this out of band.  Dispatching "click" does cause navigation,
but you have to use new MouseEvent.  This is a weird exceptional case and
should be ignored when designing new features.)

-- 
Glenn Maynard