Track NPObject ownership by the originating plugins' NPP identifier. [2/3] (Chrome)

webkit/plugins/ppapi/ppapi_webplugin_impl.cc

Index: webkit/plugins/ppapi/ppapi_webplugin_impl.cc
diff --git a/webkit/plugins/ppapi/ppapi_webplugin_impl.cc b/webkit/plugins/ppapi/ppapi_webplugin_impl.cc
index 7257f2e13559b879edcc5489106210a5c585ca4d..961546f5c0ade8b00026fbe3d5995b3e3e9595d6 100644
--- a/webkit/plugins/ppapi/ppapi_webplugin_impl.cc
+++ b/webkit/plugins/ppapi/ppapi_webplugin_impl.cc
@@ -148,6 +148,13 @@ NPObject* WebPluginImpl::scriptableObject() {
   return message_channel_np_object;
 }
 
+NPP WebPluginImpl::pluginNPP() {
+  // We must return the same pointer that the NPP parameter to NPObject binding
+  // calls will contain. WebKit will treat it as opaque, though, so it needn't

[jamesr, 2013/05/15 22:32:15]

if it's opaque anyway, can we fix the type to not be an NPAPI type?

[Wez, 2013/05/15 23:14:16]

There's not really any point in doing that right now (see scriptableObject()
above), but yes in principle this could be simply void*, or a dedicated
WebPluginId typedef, for example.

+  // be an actual NPP_t instance.
+  return reinterpret_cast<NPP>(this);
+}
+
 bool WebPluginImpl::getFormValue(WebString& value) {
   return false;
 }