In Nav3/4, plug-ins could have a Java class file that provided a Java-callable API. These plug-in Java APIs were in turn exposed through the DOM and callable from JavaScript. e.g. RealPlayer EMBEDs expose start(), stop(), pause() methods. jst is currently enhancing DOM to make it possible for Mozilla plug-ins to declare these same methods so that they are exposed in the same way, providing backward compatibility with existing content on the web that calls these plug-in Java APIs from JavaScript. Once jst's work is done, we need to enhance Andrei's sample plug-in to demonstrate how to do this. PDT has approved this enhancement to the sample plug-in as nsbeta2+. Per PDT, will mark Status [nsbeta2+]. Also marking helpwanted; would be great if member of mozilla community would help with/take on this sample code development.

Setting to [nsbeta2+]. (Earlier I forgot to mark [nsbeta2+] in status.) Note a funny thing about this particular [nsbeta2+] marking; per PDT, Andrei has approval to work on this at the [nsbeta2+] priority level due to the importance of getting this work done to assist plug-in vendors. However, this bug is not in fact an nsbeta2 blocker as it is work on a standalone sample plug-in, not the browser binary of nsbeta2 itself.

Related to my xpconnectable plugins work; reassiging to myself.

I'm removing nsbeta2+ from status whiteboard. Please remove this from nsbeta+ radar.

So here's the deal: PDT team has approved this work as [nsbeta2+] priority level (i.e. Mike is supposed to work on it along with other [nsbeta2+] bugs), but since this is sample code on mozilla.org rather than part of the browser, it's not actually an nsbeta2 stopper. So here's what I'm doing to implement the spirit and letter of PDT's decision without confusing searches or causing people to think that this is a nsbeta2 stopper: removing nsbeta2 keyword nomination, and also changing "[nsbeta2+]" in status to "nsbeta2" so it doesn't show up on searches. Mike, in the unlikely event that someone accuses you of working on a "non nsbeta2 bug," please refer them to this comment or to me.

Putting on nsbeta2- radar.

I'm not set up to work with liveconnect in Mozilla. Anybody able to test this easily? I just checked in fixes for 39933 (demonstrate plugin scripability via liveconnect) so it may be that the plugin implemented by modules/plugin/test/npsimple.cpp just works... but we need some java that shows so. Adding helpwanted.

Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because the Netscape engineer it is assigned to is overburdened.

Can this bug be closed? The page SimpleScriptableTest.html in modules/plugin/test/ demonstrates scripting a plugin instantiated using the embed tag.

mccabe has left Netscape. Reassigning this bug from mccabe to default owner -

Removing obsolete comments from status and keywords.

I think this is WONTFIX. We are nor currently planning to revive LiveConnect for using java classes to script plugins. The different approach has been implemented, see bug 37874 e.g.

v