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 <hst...@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 <ann...@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
