Re: clipboard events

On Mon, 31 Jan 2011 18:02:34 +0900, Ryosuke Niwa <rniwa@webkit.org> wrote:

>> It's simply spec'ed that way because both Firefox and WebKit agree on  
>> doing so ;)
>>
>>   Why not just pass the root editable element?
>>>
>>
>> That's what IE does.
>
>
> I think IE's behavior makes more sense.

OK. Any particular reason? Are you looking at it from the implementor's or  
the 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?

Relevant tests are for example
http://dev.w3.org/2006/webapi/clipops/testsuite/034.html (event target  
when selection spans several elements - paste event on 'a')
http://dev.w3.org/2006/webapi/clipops/testsuite/040.html (event target  
when selection spans several elements - reversed selection - paste event  
on document)
(the latter does not work in IE - no way to reverse selection. There is a  
range of tests for this, listening for the events at different elements.)

>>>  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.

>>  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.)

> 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.

Thanks again for your feedback :)

-- 
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

Received on Monday, 31 January 2011 09:31:44 UTC