W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: clipboard events

From: Daniel Cheng <dcheng@chromium.org>
Date: Mon, 31 Jan 2011 11:28:05 -0800
Message-ID: <AANLkTimdP8bpiexN+_mRn3cnrgqq4Y681=wLS6pNxM11@mail.gmail.com>
To: Ryosuke Niwa <rniwa@webkit.org>
Cc: Paul Libbrecht <paul@activemath.org>, "Hallvord R. M. Steen" <hallvord@opera.com>, public-webapps@w3.org
On Mon, Jan 31, 2011 at 09:00, Ryosuke Niwa <rniwa@webkit.org> wrote:

> 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
>
>
It is definitely less efficient, but it's already how drag-and-drop works in
Chrome.

On Mon, Jan 31, 2011 at 09:09, Ryosuke Niwa <rniwa@webkit.org> wrote:

> On Mon, Jan 31, 2011 at 3:25 AM, Paul Libbrecht <paul@activemath.org>wrote:
>
>> Le 31 janv. 2011 à 11:39, Daniel Cheng a écrit :
>> > 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.
>>
>> This is really really a hard task that I wish neither the spec nor
>> browsers implement. Here's a use case that I would find usefully implemented
>> by this spec.
>>
>> A website maker for, say, a shop for furnitures that knows they can go
>> into "my home plan maker" through the clipboard will want to be able to
>> produce and export a clipboard flavor that is unknown to both browser
>> implementors and spec makers now.
>> Provided the user may say that the format is "safe" (safe as a picture for
>> example), he would be able to drag-and-drop the furniture and get a 3D view
>> inside "my home plan maker".
>>
>
> How do we make sure it works across different platforms?  I don't think we
> should be encouraging authors to create website that only works with
> applications on a particular platform.
>
> Le 26 janv. 2011 à 06:26, Hallvord R. M. Steen a écrit :
>> > It intends to, but this has two open issues:
>> > * I assume that many OS clipboard implementations have an enumerated
>> list of "known" formats,
>>
>> Just a few of them. (I'm trying to maintain pointers to that here:
>> http://eds.activemath.org/transfers-literature )
>>
>> > I'm not sure if all OSes can handle a request to push "text/foobar" data
>> to the clipboard.
>>
>> Not an arbitrary mime-type, an arbitrary flavour conforming to the
>> platform's specifics.
>
>
>> > Does anyone know if we can rely on such functionality being truly
>> cross-platform?
>>
>> Do you mean a mapping from mime-type? No they are unfortunately extremely
>> platform specific.
>>
>
> This is the problem.  If the format is platform-specific, we'll be exposing
> platform-dependent API to the Web.  If we are to allow arbitrary data types,
> then I would really like to provide an abstraction around it so that the Web
> authors don't have to detect platform and do different things for each
> platform.  And if that's unpractical or impossible, then we shouldn't allow
> arbitrary data types.
>
> - Ryosuke
>

I think there's value in exposing arbitrary MIME types. However, my proposal
is to effectively limit them to a web sandbox so it's only visible from HTML
pages for the reasons that you listed. Exposing arbitrary types between HTML
and the native OS has potential security issues as well--a page could access
some data that it shouldn't see (e.g. filesystem paths) and it could write
malformed data into the clipboard that could crash/corrupt other programs.

Daniel
Received on Monday, 31 January 2011 19:28:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT