W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

Re: Plugin APIs (was: Agenda, Thu 26 Feb, 2009 telcon)

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
Message-ID: <20090316062028.GA10499@arc.mcc.id.au>
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:


> > 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:


Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 16 March 2009 06:21:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:10 UTC