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

Hopefully this clears things up.

How things work today:
- No pre-population.
- Cancelling the event can result in one of two things:
  - If event.clipboardData is empty, nothing happens. The system
clipboard does not change. Here, the spec differs from how browsers
behave so I've chosen to document how browsers behave. Neither Firefox
nor Chrome let you clear the contents of the clipboard by calling
event.clipboardData.clearData(). IMO, we should update the spec to
reflect this.
  - If event.clipboardData is not empty, then the changes are written
to the system clipboard.
- Otherwise, the contents of the selection are written to the clipboard.

Proposal in my first reply to Hallvord:
- Pre-population of event.clipboardData.
- Cancelling the event means the system clipboard does not change.
- Otherwise, write the contents of event.clipboardData to the system
clipboard unless event.clipboardData is empty (again, differs from the
spec but consistent with how Firefox/Chrome have implemented this for
a long time).

Advantage: This makes more sense, in that it matches dragstart
behavior (the default behavior is to start the drag for dragstart, the
default behavior for copy would be writing what's in
event.clipboardData to the clipboard).
Disadvantage: It reverses the semantics of cancelling the default
event, which is bad.

Another alternative:
- Pre-population of event.clipboardData.
- Event cancellation semantics as they work today.

Advantage: Doesn't reverse the meaning of cancelling the event.
Disadvantage: Still has behavior differences. Previously, a site could
suppress copy/cut by calling event.preventDefault(). Now it must call
event.clipboardData.clearData() and event.preventDefault(). So it's
probably not OK to do this either.

Given this, I think we're stuck with what we have.

Daniel

On Fri, Jul 12, 2013 at 1:20 PM, James Greene <james.m.greene@gmail.com> wrote:
> 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, 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
>> >>
>> >
>
>

Received on Friday, 12 July 2013 20:50:39 UTC