Re: clipboard events

On Tue, Jan 25, 2011 at 9:26 PM, Hallvord R. M. Steen <hallvord@opera.com>wrote:
>
>  On Thu, 06 Jan 2011 07:41:01 +0900, Ryosuke Niwa <rniwa@webkit.org>
> wrote:
>
>  In an editable context, the paste event's target property refers to the
>>> element that contains the start of the selection. In a non-editable
>>> document, the event is targeted at a node focused by clicking or by an
>>> interactive cursor. If the node that has focus is not a text node, the
>>> event is targeted at the BODY element.
>>>
>>>  I'm not sure if it makes sense for the element to be the start of
>> selection.
>>
>
> 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.

 Mentioning of clicking or cursor is unnecessary.  One can use keyboard to
>> move focus selection and copy / paste should still work.
>>
>
> Yes, it's meant to be an example - I added the words 'for example'.


Okay.

 compatible with
>> http://msdn.microsoft.com/en-us/library/ms535220(v=vs.85).aspx but I
>> guess getData and setData's return type prevent this.
>>
>
> I guess at least setData() and clearData() could easily return a boolean in
> HTML5 too. Ian? (I assume it indicates whether the clipboard operation
> succeeded or not).


Right.

 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.

 This sounds quite reasonable things to do but I'm not sure if we should
>> spec it.  Vendors can decide what to do by themselves.  For example, I'd
>> imagine browsers can implement some interactive UI that lets user decide
>> whether or not he/she wants to paste / copy certain content on demand.
>>  Allowing access only within the event handler might be too restrictive.
>>
>
> I think we should spec the most common and safest case. Vendors are free to
> do what they like anyway.


For the above reason, I'm strongly against such security mechanism / policy
woven into the spec.

On Thu, 06 Jan 2011 16:27:33 +0900, Ryosuke Niwa <rniwa@webkit.org> wrote:
>
>  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. It also seems a bit
> redundant, given that the event listener has access to the selection, can
> read data from there and do whatever fixes are required, then use setData().
> So I'd personally prefer the currently spec'ed text, but if others want to
> chime in and "vote for" the "show what we'll place on the clipboard" option
> I'd like to hear any arguments..


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?

- Ryosuke