- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 16 Mar 2009 17:20:28 +1100
- To: Doug Schepers <schepers@w3.org>
- Cc: Leonard Rosenthol <lrosenth@adobe.com>, public-svg-wg@w3.org
Leonard Rosenthol: > > That implies that you would need a browser-specific method? How > > would my plugin know who its parent is? Again, no standard API for > > integrating the DOM of the browser with the DOM of the plugin - or > > even just communicating back to the DOM? Doug Schepers: > Actually, communicating back to the DOM is pretty easy in Javascript: > http://www.schepers.cc/svg/blendups/scriptbridge/scriptbridge.html > > This should work in either a native implementation or using > ASV/Renesis. Am I missing something? I’m missing a bit of context, but I’ll explain my understanding of how you can get script integration with Netscape plugins. (I have no idea how you do this with ActiveX or whatever the current way of writing plugins for IE.) Within the plugin code, you can call NPN_GetValue() with NPNVPluginElementNPObject to get an NPObject for the <object> or <embed> element that loaded the plugin. On that object, you can use the usual NPN_* functions to get/set its scripted properties, to navigate the parent DOM for example. Similarly, calling NPN_GetValue() with NPNVWindowNPObject will return an NPObject for the Window object associated with the document in which the <object> or <embed> lives. By implementing the NPPVpluginScriptableNPObject variable in the plugin (via NPP_GetValue), you can provide an NPObject to the UA that will be used when properties are requested on the DOM object for the <object> or <embed> element. I think it is with this that you would expose contentDocument and contentWindow properties to script running in the outer document. In the plugin’s script engine, you would expose a property named “parent” on the global object, whose value would be an object that marshals property accesses to the NPObject that’s returned by the NPN_GetValue(…, NPNVWindowNPObject, …) call. Some limited documentation is here: https://developer.mozilla.org/en/Gecko_Plugin_API_Reference/Scripting_plugins > > Wouldn't it make more sense if we could convince the HTML5 > > committee, in their work to improve "browser experiences" for users > > to also focus on the needs of plugin developers? It seems discussions on extending the NPAPI take place on this mailing list I recently became aware of: https://mail.mozilla.org/listinfo/plugin-futures -- Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 16 March 2009 06:21:21 UTC