120822 - How to set up Mac plugin/xpt file so browser can call plugin?

Status: VERIFIED DUPLICATE of bug 154272

(Core Graveyard :: Plug-ins, defect)

Description

[Jonathan Brecher]

I have an existing Windows plugin that I'm bringing back to the Macintosh.  The 
Windows version uses the new scripting interfaces and works fine.  The Mac plugin 
is seen by the browser and can render its contents fine, but any attempt to 
access one of its exported methods generates an error of the type

JavaScript error:
http://path/to/file.html line 9: document.CDP1.getData is not a function

...where "getData" is the function that's supposedly exported by the plugin, and 
where the exact same page and function calls work just fine on Windows.

I've taken the functional xpt file from Windows, and put it in the Components 
folder on the Mac.  I deleted the xpti.dat file in that folder, and confirmed 
that my xpt file gets referenced when the xpti.dat file is regenerated.

Is this sort of scriptability thought to be working on the Mac?

I have the Mozilla source building and debuggable on the Mac, but it's sort 
of...daunting...to go burrowing around in.  If I could get a pointer in the right 
direction, I might be able to step through the code and see where things are 
going wrong...

Comment 1

[av (gone)]

Hm... So, you didn't generate this .xpt file on Mac? Did you try to do just 
that?

Comment 2

[Jonathan Brecher]

Nope, I didn't try generating the xpt file on the Mac.  I couldn't find any hint 
on how to do so.  Could you point me to instructions?  The only sort-of-relevent 
thing I could find seemed to indicate that the xpt files were binary-compatible 
cross-platform, but maybe not...

Comment 3

[Peter Lubczynski]

Unless this has regressed recently, this works for me. Here's some hints on
getting it to work:

1) See bug 112255 for a patch to Mac Perl build system
2) To make an XPT file on Mac, simply open the XML project for IDL and compile it
3) Try deleting xpti.dat

Comment 4

[Jonathan Brecher]

OK, I've cloned the nsScriptablePluginIDL.mcp project, dropped in our .idl, and 
rebuilt.  The resulting .xpt file indeed was byte-for-byte identical with the 
Windows version that I already had, with the exception of the file_length bytes, 
which were correct in the Mac build and zeroes in the Windows build.  Didn't make 
a difference in the behavior -- I still get the error message.

I've been deleting the xpti.dat file every time I turn around.  No help.

I didn't apply the perl patch.  That looks like it will simply build your 
distributed samples, which isn't going to be a big help for me.  Am I missing 
something?

I also built the 4x-scriptable plugin, and it behaves the same way -- an error 
"embed.clear is not a function".  Are you sure this is working for you?

I'll set it to pull the latest sources (I'm a few days old) over the weekend, but 
I've been watching the change logs and I haven't seen anything that looked 
relevent...

I notice that the nsScriptablePlugin.mcp project hasn't yet been carbonized.  I 
had to make those changes on my computer just to get it to load.  Is there a 
different project that I should be looking at?

Comment 5

[Peter Lubczynski]

Be sure you are using the samples in the "sdk" directory. Those are most recent
and up-to-date and should also be carbonized. If you use those samples, you'll
need the patch to the build system in order to correctly export and setup
dependant headers and idl's. 

Comment 6

[Jonathan Brecher]

OK, I've applied the patch, rebuilt everything, and regenerated every file I 
could find.  I don't know which bit made a difference, but the scriptable plugin 
sample out of the sdk directory is now working correctly.  

Unfortunately, Mozilla still refuses to talk to my plugin.  I spent a while 
stepping through the code in the hopes that it would lead me to something 
interesting, but I simply ended up failing the "if (JSVAL_IS_PRIMITIVE(v))" 
check at jsinterp.c, line 660.  I read that as a general failure to hook up with 
the function defined by my plugin, which isn't news.

What are my options for debugging this any further?  Is it worth poking around 
in the Mozilla code that tries to read in my .xpt file (or connect to 
the plugin for the first time, or something else), and could you point me in the 
right direction if so?  If I sent you my plugin, would you be able (willing?) to 
find anything useful on your end?

Comment 7

[Peter Lubczynski]

Open xpti.dat in a text editor. Do you see your interface?

Comment 8

[Jonathan Brecher]

Yup, the interface is there, and the iid is unique.  The last three numbers 
on that line after the iid (dunno if useful) are 77, -1, 1

Comment 9

[Jonathan Brecher]

As a status update, we continue to be dead in the water in terms of our plugin 
development.  I'm clearly missing some important detail, but I don't have any 
clue *what* needs to be done to get Mozilla talking to our plugin.  This issue 
and the otherwise-unrelated bug 119586 are the only two things we know about that 
are standing in the way of our release (the plugin works on Windows, so we think 
the internal logic should be fairly sound...)

Help?

Comment 10

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 11

[Peter Lubczynski]

Attachment: Simple scripting Plugin sample built for OSX (.dmg)

Comment 12

[Jonathan Brecher]

Thanks for the sample, but it doesn't help our problem.  Even the original
scriptable plugin sample (in the source tree) worked fine for me, but my plugin
doesn't.  I've matched all of the CodeWarrior project settings to your project.
 I've matched the header files to your header files.  I've rebuilt the xpt file
repeatedly (even though the original xpt file was already working correctly on
Windows, but what the hey).  Mozilla seems to be finding the xpt file, since
it's getting listed in the Components Registry.  The plugin *itself* works fine,
until you try to do anything relating to scripting, at which point scriptable
methods never get called.

I'm obviously missing *something*, but I have no clue what.

I'd be thrilled to send a copy of our plugin to anyone who is able to give us
guidance, but I'd rather not post a copy as a public attachment.  

Comment 13

[Peter Lubczynski]

This has been fixed with the checkin to bug 154272. With the fix to that bug, we
will not search for XPT files in any folder (including the global
/Libary/Internet Plugins) that has plugins as long as a plugin timestamp has
changed (like when installing a new plugin).

*** This bug has been marked as a duplicate of 154272 ***

Comment 14

[shrirang khanzode]

v

Comment 15

[shrirang khanzode]

mass duplicate verifications . For filtering purposes, pls use keywd
"massdupverification"