Modified the flash cipboard interface to add html clipboard support.

ppapi/c/private/ppb_flash_clipboard.h

Index: ppapi/c/private/ppb_flash_clipboard.h
diff --git a/ppapi/c/private/ppb_flash_clipboard.h b/ppapi/c/private/ppb_flash_clipboard.h
index 7b84a2729a570e84427f098036a0d1eab92c5fbe..ad63eadb1ea1ddf03f95ead5ab52bc0bdf62909c 100644
--- a/ppapi/c/private/ppb_flash_clipboard.h
+++ b/ppapi/c/private/ppb_flash_clipboard.h
@@ -3,7 +3,7 @@
  * found in the LICENSE file.
  */
 
-/* From private/ppb_flash_clipboard.idl modified Wed Dec 14 18:08:00 2011. */
+/* From private/ppb_flash_clipboard.idl modified Mon Jan 30 08:54:16 2012. */
 
 #ifndef PPAPI_C_PRIVATE_PPB_FLASH_CLIPBOARD_H_
 #define PPAPI_C_PRIVATE_PPB_FLASH_CLIPBOARD_H_
@@ -15,7 +15,8 @@
 #include "ppapi/c/pp_var.h"
 
 #define PPB_FLASH_CLIPBOARD_INTERFACE_3_0 "PPB_Flash_Clipboard;3.0"
-#define PPB_FLASH_CLIPBOARD_INTERFACE PPB_FLASH_CLIPBOARD_INTERFACE_3_0
+#define PPB_FLASH_CLIPBOARD_INTERFACE_4_0 "PPB_Flash_Clipboard;4.0"
+#define PPB_FLASH_CLIPBOARD_INTERFACE PPB_FLASH_CLIPBOARD_INTERFACE_4_0
 
 /**
  * @file
@@ -63,6 +64,18 @@ PP_COMPILE_ASSERT_SIZE_IN_BYTES(PP_Flash_Clipboard_Format, 4);
  */
 
 /**
+ * @addtogroup Structs
+ * @{
+ */
+struct PP_Flash_Clipboard_Data_Item {

[dmichael (off chromium), 2012/02/23 18:13:25]

This should probably be PP_FlashClipboardDataItem (though I see this is
consistent with the other names already in here). Might be worth filing a bug or
something to clean up the names, especially if we think this might ever become a
public API.

[raymes, 2012/02/24 07:28:28]

I removed this struct. I'll leave the other names as-is for now and can fix them
in a subsequent CL. Happy to file a bug, but the naming scheme is unclear to me,
even by looking at other examples. Some interfaces use pure camel case, while
others use underscores to separate components, e.g. PP_InputEvent_Key. Is it
documented somewhere?

On 2012/02/23 18:13:25, dmichael wrote:

+  PP_Flash_Clipboard_Format format;
+  struct PP_Var data;
+};
+/**
+ * @}
+ */
+
+/**
  * @addtogroup Interfaces
  * @{
  */
@@ -70,9 +83,8 @@ PP_COMPILE_ASSERT_SIZE_IN_BYTES(PP_Flash_Clipboard_Format, 4);
  * The <code>PPB_Flash_Clipboard</code> interface contains pointers to functions
  * used by Pepper Flash to access the clipboard.
  *
- * TODO(viettrungluu): Support more formats (e.g., HTML)....
  */
-struct PPB_Flash_Clipboard_3_0 {
+struct PPB_Flash_Clipboard_4_0 {
   /**
    * Checks whether a given data format is available from the given clipboard.
    * Returns true if the given format is available from the given clipboard.
@@ -81,21 +93,46 @@ struct PPB_Flash_Clipboard_3_0 {
                                PP_Flash_Clipboard_Type clipboard_type,
                                PP_Flash_Clipboard_Format format);
   /**
-   * Reads plain text data from the clipboard.
+   * Reads data in the given <code>format</code> from the clipboard. A null
+   * <code>PP_Var</code> is returned if there is an error in reading the

[dmichael (off chromium), 2012/02/23 18:13:25]

I think returning an undefined Var on error is more consistent with other
places.

[raymes, 2012/02/24 07:28:28]

Done. Undefined for an error and Null for an empty value.

+   * clipboard data.
    */
-  struct PP_Var (*ReadPlainText)(PP_Instance instance_id,
-                                 PP_Flash_Clipboard_Type clipboard_type);
+  struct PP_Var (*ReadData)(PP_Instance instance_id,

[dmichael (off chromium), 2012/02/23 18:13:25]

So this requires a synchronous message through the proxy. Would it be practical
to instead use a PP_Var out-param and a completion callback?

[raymes, 2012/02/24 07:28:28]

Spoke to vtl and according to him this is not practical because the flash API
expects a synchronous response. If we were to make this a public API then this
is something we would have to consider.

On 2012/02/23 18:13:25, dmichael wrote:

+                            PP_Flash_Clipboard_Type clipboard_type,
+                            PP_Flash_Clipboard_Format format);
   /**
-   * Writes plain text data to the clipboard. If <code>text</code> is too large,
-   * it will return <code>PP_ERROR_NOSPACE</code> and not write to the
-   * clipboard.
+   * Writes the given array of data items to the clipboard. All existing
+   * clipboard data in any format is erased before writing this data. Thus,
+   * passing an array of size 0 has the effect of clearing the clipboard without
+   * writing any data. Each data item in the array should have a different
+   * <code>PP_Flash_Clipboard_Format</code>. If multiple data items have the
+   * same format, only the last item with that format will be written.
+   * If there is an error writing any of the items in the array to the
+   * clipboard, none will be written and an error code is returned.
+   * The error code will be <code>PP_ERROR_NOSPACE</code> if the value is
+   * too large to be written, <code>PP_ERROR_BADARGUMENT</code> if a PP_Var
+   * cannot be converted into the format supplied or <code>PP_FAILED</code>
+   * if the format is not supported.
    */
+  int32_t (*WriteData)(
+      PP_Instance instance_id,
+      PP_Flash_Clipboard_Type clipboard_type,
+      uint32_t data_item_count,
+      const struct PP_Flash_Clipboard_Data_Item data_items[]);
+};
+
+typedef struct PPB_Flash_Clipboard_4_0 PPB_Flash_Clipboard;
+
+struct PPB_Flash_Clipboard_3_0 {
+  PP_Bool (*IsFormatAvailable)(PP_Instance instance_id,
+                               PP_Flash_Clipboard_Type clipboard_type,
+                               PP_Flash_Clipboard_Format format);
+  struct PP_Var (*ReadPlainText)(PP_Instance instance_id,
+                                 PP_Flash_Clipboard_Type clipboard_type);
   int32_t (*WritePlainText)(PP_Instance instance_id,
                             PP_Flash_Clipboard_Type clipboard_type,
                             struct PP_Var text);
 };
-
-typedef struct PPB_Flash_Clipboard_3_0 PPB_Flash_Clipboard;
 /**
  * @}
  */