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

On Sat, Feb 18, 2012 at 07:28, Hallvord R. M. Steen <hallvord@opera.com>wrote:

> On Fri, 17 Feb 2012 19:23:29 +0100, Daniel Cheng <dcheng@chromium.org>
> wrote:
>
>  Also, what does it mean to be "supported"? In new versions of Chrome, any
>> kind of MIME type is supported in the sense that you can set data for any
>> arbitrary type, and it can be understood by any browser that uses the same
>> native conventions (I'd be happy to work with any other developers
>> interested in making sure this works across different browsers on the same
>> computer).
>>
>
> That's interesting. How do you do that, on Windows in particular? Have you
> registered a clipboard format called "MIME type of main clipboard part"
> where you store type strings, or something?
>
>
> --
> Hallvord R. M. Steen, Core Tester, Opera Software
> http://www.opera.com http://my.opera.com/hallvors/
>

Chrome registers a clipboard format on Windows called "Chromium Web Custom
MIME Data Format" (we do the same thing on Mac and Linux at the moment to
keep the various implementations similar), and when we see an attempt to
add data of a type which we don't have a native translation for, we just
place the string in there. We currently have a bug open to figure out how
to standardize the serialization, so we can stop using the
Chromium-specific types. I'd like to extend it to binary data at some point
too.

With respect to enabling copy/cut/paste in context menu items, IE/WebKit
have beforecut/beforepaste (both) and beforecopy (WebKit only?) events that
fire before a context menu is displayed. I'm not sure how widely used they
are though. That being said, it'd be nice to have something that works well
for native context menus and custom editing controls created with HTML
elements like the one at http://ckeditor.com/demo.

Daniel

Received on Monday, 20 February 2012 04:15:28 UTC