Re: clipboard events

On Mon, Jan 31, 2011 at 1:31 AM, Hallvord R. M. Steen <hallvord@opera.com>wrote:

> On Mon, 31 Jan 2011 18:02:34 +0900, Ryosuke Niwa <rniwa@webkit.org> wrote:
> OK. Any particular reason? Are you looking at it from the implementor's or
> the script author's perspective?
>

>From script author's perspective.

Because of your E-mail address, I sort of assume that WebKit would be happy
> to change if we spec IE's behaviour :). Perhaps someone from Gecko could
> comment too?
>

I can't speak for the entire WebKit community.  However, I'll argue for
changing the behavior if the spec is changed to use the root editable
element.

  Internet Explorer already implements most of this spec but ClipboardData
>>>> is
>>>> implemented as a property of window object. Why deviate?
>>>>
>>>
>  To me it seems to express much more clearly that this stuff is only
>>> available as a consequence of those events being triggered by the user.
>>> As
>>> such, event.clipboardData seems nicer than window.clipboardData.
>>> (Besides,
>>> both WebKit and Gecko already made this decision and it seems a useful
>>> way
>>> to let developers object-detect HTML5's stuff versus legacy IE stuff.)
>>>
>>>
>> I'm not sure we should allow access to clipboard only when those events
>> are
>> fired.  I can see browsers that support application stores might want to
>> allow purchased apps to be able to access clipboard access.  Also, browser
>> vendors can permit users to grant clipboard access permissions to certain
>> websites that act more like natives apps.  And for those apps,
>> event.clipboardData isn't sufficient.  And I don't think we should be
>> limiting such use cases by the spec.
>>
>
> I think that is outside the scope of this spec. It's a spec for clipboard
> *events*, not for general clipboard access, and I'd like to keep that scope.


Okay.

  If getData() is not called from within a paste event handler, or if the
>>>
>>>> type is not available, the method returns undefined
>>>>>
>>>>>
>>>>   What should we do if getData is called within a copy event handler?
>>> We
>>>
>>>> have an outstanding bug that requests that getData returns the content
>>>> that's about to be copied into the clipboard (
>>>> https://bugs.webkit.org/show_bug.cgi?id=22017).  Should we consider
>>>> such
>>>> a behavior?
>>>>
>>>>
>>> Thanks for the bug reference, an interesting and very relevant issue. I
>>> don't think it really makes sense to do what the bug reporter requests,
>>> because the copy event fires *before* the copy operation takes place. At
>>> the
>>> time, whatever data was on the clipboard previously will still be there,
>>> returning that in getData() doesn't seem to have much of a use case.
>>> Returning the new data you're about to copy seems a bit confusing since
>>> it's
>>> not actually the data that is on the clipboard.
>>>
>>
> (Did you agree with this reasoning, by the way? You didn't comment on
> this.)


I think returning the contents in getData makes sense.  i.e. I agree with
your reasoning.

 Another thing. Should getData guarantee to return the same result each time
>> called within the same event handler?  i.e. if some external applications
>> overrode clipboard's data between two calls to getData, what should
>> happen?
>>
>
> IMO getData() should be 'live' - i.e. return what's on the clipboard. Do
> you think that is harder to implement or less performant than the other
> possible behaviour? I guess it might give less performance, but I doubt
> repeated calls to getData() is a use case worth optimising for.
>

Making it live seems more efficient.  If we allowed arbitrary MIME types and
spec'ed to always return the same data, then we must copy contents in the
clipboard of all MIME types into some internal data structure.  This will
create a huge performance bottle-neck because even if the page never called
getData, we need to make copies of, say, a 5MB jpeg image and the
corresponding 100MB bmp along with various other MIME types in the clipboard
when firing paste or copy event.

- Ryosuke