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