Re: clipboard events

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

> On Mon, 31 Jan 2011 18:02:34 +0900, Ryosuke Niwa <rniwa@webkit.org> wrote:
>
> 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/
>
>
I think having it return live data could result in potential security
issues. Couldn't a script loop inside the paste event to keep sniffing out
live data?

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

> On Thu, 27 Jan 2011 05:12:58 +0900, Daniel Cheng <dcheng@chromium.org>
> wrote:
>
>  Platform capabilities vary.
>> - Windows will be unhappy if you use up all the custom clipboard formats
>> (~65535 or so). There is no way to release formats once registered.
>> - Mac uses UTIs which are strings but not MIME types.
>> - GTK+ seems to support arbitrary MIME types.
>> So for push support, Windows will be unable to natively support arbitrary
>> string types.
>>
>
> Thanks. Do you think it is OK to say that we allow arbitrary strings but it
> may not be available on all platforms, and recommend that script authors
> stick to known MIME types?


I'd go one step further and say that there should be some agreement on what
MIME types ought to be supported to try to insure somewhat consistent
behavior across different platforms. The way I'm working on implementing it
(for drag and drop, though it applies to copy and paste as well), arbitrary
strings would not be accessible from a non-DOM application, e.g. a native
app like Word or Photoshop. Only a set of known MIME types would be
automatically converted to the corresponding native type.


>
>
>  When pulling data from the clipboard, I wonder if it may also be a bad
>> idea
>> to expose all the native types. I was working on a patch to do this in
>> WebKit, and it turns out some of the native types leak information about
>> filesystem paths when files are involved in the dragging/paste operation.
>>
>
> Do you remember any further details? Seems like something we should mention
> but I don't know how.


Since Linux uses MIME types in its clipboard, I changed the Clipboard
implementation in WebKit to directly mirror the contents of the native
clipboard. As a result though, pages could access a bunch of random types
that included full filesystem paths as part of their data when dragging a
file. I suspect that the list of types that happens to leak filesystem paths
will vary based on the window manager in use. Because of this, I'm choosing
to restrict the number of native types to a smaller, defined set that are
visible to webpages. Any paths in this set can be filtered as necessary when
a file drag is detected.


>
>
>  * There is not yet a clear way to push multi-part or alternate formats to
>>> the OS clipboard from JS. To use something like iCal, I guess best
>>> practise
>>> would be to push one human-readable text/plain string for target software
>>> without iCal support, and one alternate entry in iCal format. I guess
>>> that
>>> can be done with
>>>
>>>  DataTransferItem add(in DOMString data, in DOMString type);
>>>
>>> I.e. spec for copy event would be
>>> * default action: copy any document selection
>>> * if default action is prevented: push data in drag data store (as
>>> manipulated by setData() or items.add()) to clipboard, probably mapping
>>> certain known values to native clipboard formats while doing so.
>>>
>>>
>> If the default action is prevented and no data was added to the drag data
>> store, does that imply the clipboard should be cleared?
>>
>
> No, that sounds like it should be a no-op to me. Does the spec now imply
> otherwise?
>
>
> --
> Hallvord R. M. Steen, Core Tester, Opera Software
> http://www.opera.com http://my.opera.com/hallvors/
>

>From a strict interpretation, preventing the default event should push an
empty drag data store onto the clipboard--e.g. erasing it. I believe it
should be a no-op instead.

Daniel