195264 - Provide examples of passing COM objects btw CFM<->Mach-O browsers/plugins

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Jonathan Brecher]

User-Agent:       Mozilla/4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC)
Build Identifier: 

Bug 182117 introduced changes so that it's now possible to make a scriptable 
plugin that will be compatible with a Mach-O browser.  However, it's still not 
possible to install more than one version of a plugin at a time, so it's really 
tough to get the right plugin installed on a user's machine.  That bug references 
bug 72083, which shows how to implement an XPCOM vtable "from scratch" in plain 
C.  That seems to be the best way to solve the remaining practical problems: CFM 
plugins talking to CFM browsers can send native objects, Mach-O plugins talking 
to Mach-O browsers can also send native objects, and CFM/Mach-O plugins talking 
to Mach-O/CFM browsers can synthesize the required vtables by hand.

Which leaves the critical question: what *are* the required vtables?  If this is 
going to be the recommended approach, we really really need examples!  What is 
the proper way to create a suitable Mach-O vtable from CFM code?  What is the 
proper way to create a suitable CFM vtable from Mach-O code?  We'd love to see 
the first as soon as posssible, and the second one in the long term...


Reproducible: Always

Steps to Reproduce:


Actual Results:  



Expected Results:

Comment 1

[Peter Lubczynski]

I've created a sample of a plugin that's scriptable in both gcc 3.x and 2.x
browsers on Linux. Here's what I did to build my plugin with gcc 3.x but
added-in scripting support for gcc 2.x so it can work with current browsers:

1. Pull two trees. Build one with gcc 2.x and another with gcc 3.x. Set 'CC' and
'CXX' to the path of your compiler. Build and install the plugin sdk simple
scripting sample in modules/plugin/tools/sdk/simple and verify its workings with
your build before modifying it.

2. In your gcc 2.x nsScriptablePeer.cpp, add an export C function that can
return the allocated class in the right ABI. For example, here's what I did:

extern "C" void * PLUGIN_GetScriptablePeer()
{
  nsScriptablePeer * raw = new nsScriptablePeer(NULL); // XXX fix ctor args

  nsISupports *myPtr;  
  raw->QueryInterface(kISupportsIID, (void**)&myPtr); // XXX QI to addref
  
  return myPtr;
}

3. Fixup the scriptable interface method |nsScriptablePeer::GetVersion| in that
file for the time being such that it returns some string for testing rather than
trying to dereference mPlugin which will be null and using the wrong ABI anyway.
You'll probably want to eventually proxy calls to your gcc 2.x and 3.x methods
on the back-end to common implementation through C functions.

4. Build your plugin with gcc 2.x and for the time being, install it to /tmp
rather than any plugins folder. Since your 2.x library still has exported NPAPI
functions, the browser may try to load this library as the plugin instead of
your 3.x library if it's in the browser's plugin path. If you remove these
functions you can put this library next to your plugin. Only your plugin should
be loading this library.

5. Now in your 3.x plugin, to hook all of this up, you'll want to add another
case for (NPPVpluginScriptableInstance xor(^) NP_ABI_GCC3_MASK) in |GetValue|.
For this case, you'll want to dynamically load your 2.x scripting library and
call your exported function you made in step #2 that returns the class in the
right ABI for the browser. For example, I have this code:

void * lib = dlopen("/tmp/libnpsimple.so", RTLD_LAZY);

typedef void *(*PLUG_GetScriptablePeer_func)();
PLUGIN_GetScriptablePeer_func getPeer = 
  (PLUGIN_GetScriptablePeer_func) dlsym(lib, "PLUGIN_GetScriptablePeer");

nsISimplePlugin * scriptablePeer = getPeer();
*(nsISupports **)aValue = scriptablePeer;

That's it. Build your 3.x plugin and put it in the browser's plugin search path.
So now when it comes time for scripting in a gcc 3.x browser, your plugin
returns the linked in version of your scriptable class as it always did because
the ABIs match. However in a gcc 2.x browser, the browser doesn't apply the 3.x
mask to the enum so you use this fact to trigger dynamically loading and
allocating your gcc 2.x compiled scripting class.

Note that you may also have to pass in the browser's allocator to this new library.

Since I've got this sample working with Linux, the next step is to make a sample
for Mac that also uses the CFM<-->MachO glue code between C functions. I'll also
want to put my extra scripting library in a bundle for nice packaging.

Comment 2

[Georg Fritzsche [:gfritzsche]]

XPCOM scripting for plugins is gone since Fx 3.6 already.