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

Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Fri, 17 Feb 2012 10:25:02 -0800
Message-ID: <CABNRm61B-u6njwRZpNFYB0oUgY4ctQNm4p9k3XbBtq6PMGtrQg@mail.gmail.com>
To: Paul Libbrecht <paul@hoplahup.net>
Cc: "Hallvord R. M. Steen" <hallvord@opera.com>, public-webapps@w3.org
On Fri, Feb 17, 2012 at 10:10 AM, Paul Libbrecht <paul@hoplahup.net> wrote:
> I have one concern: media-types are likely to be insufficient and "flavour
> names", whatever they are on the host platform should be allowed I think.
> Almost arbitrary strings on Windows and Uniform Type Identifiers on Mac
> should be allowed, I think.

Realistically, I don't think we'll ever let the wild Web get/set arbitrary
data like that. But maybe we can do that for privileged websites (ones that
the user trusts).

Le 17 févr. 2012 à 18:53,
> Ryosuke Niwa
> Software Engineer
> Google Inc.
> a écrit :
> Also, I'm thinking if there are cases where the supported mime types
> change dynamically without reloading the page.
> (I hope I patched correctly)


Yes, it does happen: I think I know that in Windows the supported
> flavour-names depend on the launched applications. On Mac it depends on the
> applications whose descriptor has been loaded (by the Finder I think, it
> might also be those that have been launched once). At least an
> application download and launch can cause a change in the supported
> media-types of the OS.

Right. These will become problems if we decide to expose all platform types.

However, would the browsers be informed of such a change? Would they be
> able to consider a given type as being safe and not needing a sanitization?

I don't think that's possible without some sort of pre-knowledge about how
the data is processed. In practice, we always hard-code this kind of
information somewhere so I'm even not sure if such an elaborate behavior
can be implemented.

- Ryosuke
Received on Friday, 17 February 2012 18:25:52 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC