Re: clipboard events

On 01/31/2011 11:02 AM, Ryosuke Niwa wrote:
> On Tue, Jan 25, 2011 at 9:26 PM, Hallvord R. M. Steen
> <hallvord@opera.com <mailto:hallvord@opera.com>> wrote:
>
>     On Thu, 06 Jan 2011 07:41:01 +0900, Ryosuke Niwa <rniwa@webkit.org
>     <mailto: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.

I think Webkit's and Gecko's behavior makes more sense.
You paste to some location in the editable area, not to root of it.


-Olli


>
>         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
>     <mailto: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
>

Received on Tuesday, 17 May 2011 08:17:41 UTC