Re: Clipboard API: Default content in copy/cut handlers

Sorry, I think I must've misunderstand what your original proposed changes
were as I thought you meant that the DataTransfer interface's items weren't
being pre-populated on the ClipboardEvent's clipboardData property for
beforecopy/copy events.  Now I'm thinking that THAT is already in place and
you are just suggesting a change in what is considered the default behavior
once there is a registered listener for the beforecopy/copy event(s).

Node.js does a similar behavioral switch-up for uncaught exceptions.
 Normally an uncaught exception results in printing the stack trace and
then exiting the process; however, if you add a listener for the
`uncaughtException`
event <http://nodejs.org/api/process.html#process_event_uncaughtexception>,
then this default behavior will NOT happen and it's left up completely to
the handler to choose whether to print a stack trace, exit the process, etc.

Sincerely,
    James Greene



On Fri, Jul 12, 2013 at 3:07 PM, Daniel Cheng <dcheng@google.com> wrote:

> The problem is backwards compatibility. There are sites that use the
> copy/cut event handler, and the proposal reverses the behavior.
> Suppose it were implemented:
>
> On older browsers: You must call event.preventDefault() in order for
> your changes to be written to the clipboard.
> On newer browsers: You must NOT call event.preventDefault() in order
> for your changes to be written to the clipboard.
>
> This transition would be extremely confusing, even if the proposal
> does seem more intuitive =/
>
> Daniel
>
> On Fri, Jul 12, 2013 at 12:20 PM, James Greene <james.m.greene@gmail.com>
> wrote:
> > Right, I think this makes total sense.  A common example might be to add
> > your page's URL, copyright notice, etc. to the end of whatever text the
> user
> > has selected WITHOUT having to query the Selection/Range APIs to
> [hopefully]
> > retrieve their selected text.
> >
> > I am discouraged, however, to see someone who works for a browser vendor
> > lamenting that doing it in what is likely the "right way" may be
> impossible
> > because a number of browser vendors have already implemented the
> > functionality.  To me, it doesn't really seem like adding this new
> behavior
> > would negatively affect the current APIs at all as no one is expecting to
> > have that data provided on the Event right now; the only real change
> here is
> > in the browser internals, and consumers can take advantage of such by
> > eliminating their current Selection/Range queries once the Event is
> > providing that data on their behalf.
> >
> > As someone who is not a browser vendor employee, this sounds very doable.
> > ;)
> >
> > Sincerely,
> >     James Greene
> >
> >
> >
> >
> > On Fri, Jul 12, 2013 at 2:05 PM, Daniel Cheng <dcheng@google.com> wrote:
> >>
> >> On Fri, Jul 12, 2013 at 12:56 AM, Paul Libbrecht <paul@hoplahup.net>
> >> wrote:
> >> > Is there any reason to justify the requirement to populate before the
> >> > dragstart?
> >>
> >> My guess is that it's a convenience for authors to be able to modify
> >> the content from the default easily.
> >>
> >> On Fri, Jul 12, 2013 at 5:22 AM, Hallvord Reiar Michaelsen Steen
> >> <hallvord@opera.com> wrote:
> >> > Regarding the question: I'm not sure what exactly you're asking for
> with
> >> > "something similar" and what effect it would have. Is it about reading
> >> > from
> >> > clipboard (for example, since you mention  DnD of files, like reading
> >> > pasted
> >> > file references in a paste event)? Writing to the clipboard? Is there
> >> > any
> >> > change the clipboard spec should make to make pasting files/folders
> >> > easier
> >> > to implement? If yes, how and why?
> >>
> >> My original idea is that prior to dispatching a copy/cut event, run
> >> "if there is a selection, place the contents of the selection in the
> >> data store", then dispatch the copy/cut event.
> >>
> >> If the copy/cut event is not cancelled, then:
> >> - Write the data store to the clipboard.
> >>
> >> If the copy/cut event is cancelled:
> >> - Do nothing. The data store is discarded and the changes are not
> >> written to the clipboard.
> >>
> >> Unfortunately, this is completely opposite of how it's handled today
> >> by Firefox/Chrome/Safari so I don't think we can do this. Oh well.
> >>
> >> Daniel
> >>
> >
>