127710 - ActiveX plugin (npmozax.dll) should allow Javascript/scripting through LiveConnect and XPConnect

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: ActiveX Wrapper, defect)

Description

[Paul Oswald's old account]

I have extended Adam Lock's plugin to work with JavaScript through LiveConnect.
This allows the embedded ActiveX control to be scriptable from 4.x browsers. We
also have a preliminary XPConnect version coming along. 

I took Adam Lock's lead and implemented the Java class such that you can call:

var = pluginName.GetProperty("ActiveXPropertyName");
pluginName.Invoke("ActiveXMethodName");
alert(pluginName.npmozaxVersion());

In the first case it will return the associated property. The last line is one I
use to keep track of each build, implemented in the Java class file. I guess it 
is strictly not necessary but might be useful if the way we call things changes.

Speaking of which... I would like to bring up an issue: Is it possible to have
the Java class load up a run-time instance with an interface that matches the
ActiveX control? Can we do this in XPConnect? This way all sites that use
ActiveX will work seamlessly since we would be doing it the same way as IE:

var = pluginName.ActiveXPropertyName;
pluginName.ActiveXMethodName();
alert(pluginName.npmozaxVersion());

Comment 1

[Paul Oswald's old account]

Attachment: LiveConnect patch for npmozax.dll

Here's the patch. It does not support overloaded Invokes() yet because I had
some trouble getting it to compile. I was also useing a different Java SDK than
Adam was so you will probably have to change that line in makefile.win

This patch was made against 0.9.8 but I think I may have included the patch
from http://bugzilla.mozilla.org/show_bug.cgi?id=46569 when I made it. Just run
this in mozilla/embedding/browser/activex/src/plugin.

I am not great at the whole patching/diff procedure and I get cvs through my
firewall so if I did it wrong, please let me know what I need to do to fix it.

Comment 2

[Paul Oswald's old account]

Oops! I meant to say that I included the patch from bug 126492 above (not 46569).

Also I wanted to mention that I included a .dsw and a .dsp file for Visual C++
but you might have to change the program and dll locations in the settings
before building. I also changed the makefile to drop the dll directly into the
plugins folder so that I could debug by pressing F5 from VC.

Comment 3

[Peter Lubczynski]

Nice patch, but Mozilla does not support the old Liveconnect way of scripting
plugins. However, I think there may be an XPConnect bridge in the works.

-->over to Adam Lock for review

Comment 4

[Paul Oswald's old account]

I understand that the mozilla browser does not support LiveConnect. No code in
the browser has been changed at all. Furthermore, if you comment out the
LiveConnect variable in Makefile.win you will get the plugin without any of the
code in the patch. I think that optionally allowing the plugin to support
Netscape 4.x (LiveConnect) as well as Mozilla (XPConnect) adds value.

My question concerning this XPConnect bridge is as follows: is there a way to
have the interface that XPConnect presents to Javascript definable at runtime?
The only method I see is outlined on http://mozilla.org/docs/plugin.html and
would consist of compiling the plugin against a type library. This method will
require the npmozax plugin users to make a GetProperty() call in Javascript like
I have done in the LiveConnect patch. Allowing XPConnect to provide interfaces
at run time would put it more on par with Microsoft's COM.

Comment 5

[Paul Oswald's old account]

On or around line 386 of LegacyPlugin.cpp I put the following in NPP_Destroy()
to keep the plugin from calling into a non-initialized pointer:

#ifndef MOZ_ACTIVEX_PLUGIN_LIVECONNECT
            pData->pScriptingPeer->Release();
#endif /*  MOZ_ACTIVEX_PLUGIN_LIVECONNECT  */

Now that I'm looking into the XPConnect stuff I see that this is a bug in the
XPConnect version as well. The real fix should be to set the pointer
pData->pScriptingPeer to NULL when it gets created by new up in NPP_New(). This
way it gets detected as NULL by NPP_GetValue() and gets initialized. The end of
NPP_New() should be:

NPError NP_LOADDS NPP_New(NPMIMEType pluginType,
                NPP instance,
                uint16 mode,
                int16 argc,
                char* argn[],
                char* argv[],
                NPSavedData* saved)
{
    . . . 

    pData->pScriptingPeer = NULL;    //  <-- this is the line to add.
    instance->pdata = pData;
    return NPERR_NO_ERROR;
}


That should fix the dialogs that pop up in XPConnect versions and allow us to
remove the #ifndef MOZ_ACTIVEX_PLUGIN_LIVECONNECT from NPP_Destroy() for 4.x
versions as well.

Comment 6

[Patrick C. Beard]

In comment #4, [e-mail] wrote:
>My question concerning this XPConnect bridge is as follows: is there a
>way to have the interface that XPConnect presents to Javascript
>definable at runtime? The only method I see is outlined on
>http://mozilla.org/docs/plugin.html and would consist of compiling the
>plugin against a type library. This method will require the npmozax
>plugin users to make a GetProperty() call in Javascript like I have
>done in the LiveConnect patch. Allowing XPConnect to provide
>interfaces at run time would put it more on par with Microsoft's COM.

Yes, the interface a scriptable plugin presents to XPConnect is
definable at runtime. If different interfaces are used, the multiple
type libraries will be necessary for all of the possible interfaces.

Comment 7

[Patrick C. Beard]

Hmm, perhaps definable is too strong a word, I really meant to say 
"selectable". I don't know if we have any support for constructing type 
libraries at runtime.

Comment 8

[Adam Lock]

An XPConnect bridge that allows the JS to call arbitrary methods on the plugin
would be nice. Internally the plugin would receive the call and args and pass
them to the real control for processing via IDispatch.

Comment 9

[Paul Oswald's old account]

I have Invoke() working with XPConnect->ActiveX. Currently, I am working on
passing parameters back to JavaScript. (I am currently trying to figure out if I
can return a generic object to Javascript. In the LiveConnect version I was
returning a java_lang_Object* from the native methods. I am looking for the
equivalent idea in JavaScript.) Once that is done, GetProperty() should work as
well. If you would like to see what I have so far, I could post another patch.
Otherwise, I expect to have this done by the end of the week.

I would love to be able to construct an interface at runtime so that we could
call the functions directly without passing them as parameters to Invoke(), but
I just don't see how it is possible with XPConnect in its current form. Does
anyone see a way? For my purposes, calling name.Invoke("function") is
sufficient, since I can just write out my own Javascript to call it. If anyone
wants npmozax.dll to be scriptable with existing IE content, then XPConnect
would have to support calling: name.function()  I don't even know how common
scripted ActiveX controls are on the web.

The problem seems to come down to the mechanism of typelibs. In Ms COM, typelibs
are used to create VTable interfaces which are faster but can only be used at
build time. You can also have run-time IDispatch interfaces which are what the
Scripting languages use. A COM object can also be defined to have dual interfaces.

Comment 10

[Paul Oswald's old account]

Attachment: Support for ActiveX invoke() and getProperty() through XPConnect

This patch supports invoke() and getProperty() through LiveConnect -or-
XPConnect. I built it against a snapshot I downloaded today so it should work
ok.

I took out the dsw and dsp files since they were getting messed up.

Also, I added ifdefs to the makefile.win and Legacyplugin.cpp so you can choose
what kind of support you want to build.

Could someone else please test this version for me?

Again, sorry if the patch itself is not the best quality. If anyone has any
tips on how I can do it better I would love to hear them.

Comment 11

[Paul Oswald's old account]

Attachment: VisualC++ dsp file

Comment 12

[Paul Oswald's old account]

Attachment: VisualC++ dsw file

Comment 13

[Paul Oswald's old account]

I have tested this code with XPConnect and Mozilla 0.9.9 on Win2k and it seems
to work ok for me. It was originally developed on Win95 and Mozilla 0.9.8. I am
having trouble getting my code to work on Netscape 4.79 on Windows 2000. It
fails around this line in GetProperty():

    const char* property = JRI_GetStringUTFChars( env, a );
--> NPP npp = (NPP)self->getPeer(env);

This ends up calling the function:
    return (jint)JRI_CallMethodInt(env)(env, JRI_CallMethod_op, self,
methodID_netscape_plugin_Plugin_getPeer);
which fails with an unhandled exception.

It is my understanding that LiveConnect is not (nor will ever be) part of
mozilla, however this is where Adam's ActiveX control is hosted, and it seems
like it would be good functionality to have for Netscape 4.x. Is anyone else out
there testing any of this code with either XPConnect or LiveConnect?

Comment 14

[Adam Lock]

Future.

Patches looks good so I will attempt to incorporate them into the plugin when
time allows.

Comment 15

[Paul Oswald's old account]

Attachment: updated LegacyPlugin.cpp

Adam, 

Thanks for reviewing and accepting the patch. We have since updated
LegacyPlugin.cpp to incorporate SetProperty() for LiveConnect and XPConnect as
well. There is also a GetNProperty() in the XPConnect implementation that will
return a value as a true JavaScript number type. I could not find a way to
return a number type using overloading, so this is the way we went. I don't
know if you will want to bother including that. GetProperty() can simply do an
itoa() conversion.

I also figured out that the problems I was having with 4.x on win2k was due to
a problem with the npp->getPeer call. This was a FAQ on the newsgroups a while
ago and is fixed here.

Good luck with the 1.0 release. I'm sure you are all very busy.

Comment 16

[Paul Oswald's old account]

Attachment: updated interfaces idl file

includes interfaces for Get and SetProperty()

Comment 17

[Adam Lock]

Attachment: Unified patch

This patch is a substantially cleaned up and unified version of the preceding
ones. I've also rewritten makefile.win to stick all the configurable things
closer to the top.

The plugin builds with no scripting support and with LiveConnect but there is a
nasty dependency issue in XPConnect - it's dependent on nsMemory::Alloc and I'd
like to be able to squash that if possible.

This patch builds but scripting has not been tested to see if it works. From
the looks of it, a lot of the LiveConnect/XPConnect functionality (e.g. in the
Invoke functions) should be shared.

I am mulling over checkin options. Since the plugin has NO scripting at the
moment, and all the scripting code is #ifdef'd I don't see any harm checking in
with if XPConnect/LiveConnect stuff disabled by the makefile.

Comment 18

[Adam Lock]

I've checked in the scripting work in progress as is. The makefile.win disables
LiveConnect/XPConnect support by default so it should behave exactly as before
unless you uncomment the settings that turn this feature on.

XPConnect has a link error so I commented out the actual functionality in the
script peer methods until we can figure a way to allocate XPCOM memory without
pulling in XPCOM (if that's possible). 

LiveConnect builds but I'm still having problems trying to persuade NS 4.x that
it actually is a LiveConnect'ed plugin. Once I resolve these I will actually be
able to work on the invoke/set/getProperty methods. I've copied npmozax.dll &
MozAxPlugin.class into the plugins dir and my NPP_GetJavaClass looks right so
I'm not sure why its reporting my object has no methods or properties. Does
anyone have any ideas?

I'll will attach the documentation for the defunct NCompass ActiveX plugin
(dragged from www.archive.org) which I've been using as a reference as a good
way to expose ActiveX via LiveConnect.

Comment 19

[Adam Lock]

Attachment: NCompass - Activating Your Web Site with ScriptActive

Comment 20

[Adam Lock]

Attachment: NCompass - Authoring ActiveX Controls for the ScriptActive Plug-in

Comment 21

[Adam Lock]

See also here for a few other bits and pieces:

http://web1.archive.org/web/19970605090529/www.ncompasslabs.com/scriptactive/dev_document.htm

Comment 22

[Adam Lock]

Made another checkin today. The major issues with LiveConnect (pure evil!) have
been resolved and the plugin now has basic functionality - invoke() works and
setProperty() might too. I checked in a simple test_liveconnect.html to try it
out. Build with LiveConnect enabled and copy MozAxPlugin.class and npmozax.dll
to the plugins dir to have a go.

I have another checkin pending to make the plugin recognize more basic Java
types (current it only does strings), like java.lang.Boolean etc. and convert
them into the IDispatch VARIANT counterparts.

The getProperty impl will take a little more work since I will have to write a
_VariantToJRIObject method to process the result back into LiveConnect land. The
same goes for returning a result from the invoke() method.

LiveConnect & XPConnect should probably live in seperate files since their impl
is going to be quite big. I have yet to do anything significant with XPConnect.

Comment 23

[Adam Lock]

An update on progress:

LiveConnect is working pretty well. I have invoke, setProperty & getProperty
working with all the hell using JRI and LiveConnect pretty much sorted. I have
converters to convert VARIANTs to Java objects and vice versa and versions of
invoke for 1-4 arguments and also an arg array (untested). Double & Float
support isn't there yet because the java.lang.Double/Float classes have some
native methods that I have to implement and haven't gotten around to.

XPConnect is working, but still rudimentary. Invoke & setProperty work,
getProperty is still commented out. The invoke method takes no arguments and one
of the things to figure out is the best way let it take multiple args of varying
types.

Plugin can be built with no scripting support, or with LiveConnect and/or
XPConnect support.

Still to do:

Doubles & Floats. Event sinks (future enhancement). Align plugin direction with
David's work on COM support in JS (tomorrow). Makefile is old style makefile.win
and won't work with gmake builds without copying xpidl.exe and some other tools
into dist\win32_d.obj\bin.

Once LiveConnect & XPConnect are working more or less without obvious issues
I'll mark this bug fixed. Future issues can be dealt by new bugs.

Comment 24

[Adam Lock]

XPConnect & LiveConnect scripting are both working now. Visit
http://www.iol.ie/~locka/mozilla/mozilla.htm for more info.

Marking FIXED.-