303241 - [OS/2] Java does not work in builds after 7-21

Status: RESOLVED FIXED

(Core Graveyard :: Java: OJI, defect)

Description

[Andy Willis (abwillis)]

Java does not work in Seamonkey or Firefox builds since 7-21 (7-21 works but
7-22 and beyond does not).

Comment 1

[Andy Willis (abwillis)]

Downloaded an 8-03 windows build and java works in it so this is OS/2 only.

Comment 2

[Mike Kaply [:mkaply]]

This was caused by the checkin for:

https://bugzilla.mozilla.org/show_bug.cgi?id=296561

In particular, after this checkin, calling NSGetModule on ipluginw.dll is
failing, so the component never registers:

https://bugzilla.mozilla.org/show_bug.cgi?id=296561

The return code is 0x8000FFF which is simply NS_ERROR_UNEXPECTED.

Comment 3

[Mike Kaply [:mkaply]]

Just to be clear here, the initial load of the ipluginw component is what is
failing. We never actually get into plugin code.

To recreate, you have to delete compreg.dat and debug component registration.

Watch here:

http://lxr.mozilla.org/seamonkey/source/xpcom/components/xcDll.cpp#249

for when ipluginw.dll is attempted.

You'll find that rv is NS_ERROR_FAILURE

looking at the source code for ipluginw, the only logical error path is the
final return where the QueryInterface is happening. So somehow that is failing.

Comment 4

[knut st. osmundsen]

This is the reason why it's busted:

Index: xpcom/glue/nsGenericFactory.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpcom/glue/nsGenericFactory.cpp,v
retrieving revision 1.61
diff -u -4 -r1.61 nsGenericFactory.cpp
--- xpcom/glue/nsGenericFactory.cpp	14 Jul 2005 18:42:58 -0000	1.61
+++ xpcom/glue/nsGenericFactory.cpp	21 Jul 2005 13:23:43 -0000
@@ -474,9 +474,9 @@
     return NS_ERROR_FAILURE;
 }
 
 NS_COM_GLUE nsresult
-NS_NewGenericModule2(nsModuleInfo* info, nsIModule* *result)
+NS_NewGenericModule2(nsModuleInfo const *info, nsIModule* *result)
 {
     nsresult rv = NS_OK;
 
     // Create and initialize the module instance


The NS_NewGenericModule2 signature changed with that 'const' addition causing
ipluginw.dll to fail when (dynamically) resolving the symbol in its
NS_NewGenericModule2() wrapper. I can change ipluginw to look for both
signatures. I could also _try_ talk my boss into opening ipluginw if anyone is
is interested in that - it'll certainly help keeping it in sync with the rest of
mozilla.

Comment 5

[Benjamin Smedberg]

NS_NewGenericModule2 is a glue (nonfrozen) function... if you need to be
compatible with old binaries that accidentally imported it, then you do need to
deal with those multiple mangled C++ symbols.

Comment 6

[knut st. osmundsen]

Attachment: New ipluginw.dll

Comment 7

[Steve Wendt]

Knut, was this new DLL supposed to work with new builds?

Rich Walsh says:

I just tried it.  As soon as I mouse over a Flash animation, Fx crashes
(both flash 5 & 7).  And, my java test site doesn't work either.

As described in Bug 303241, the name of a function that ipluginw requires
has changed.  The impression I got from Knut's comments was that he'd have
the new version look for both the old & new names to maintain compatibility.
However, when I look at the new file, I only see a reference to the old name.

William Hartzell says:

I can affirm that this dll does *NOT* work with current trunk builds of SeaMonkey.

Comment 8

[knut st. osmundsen]

Arg! The fix didn't make it into our CVS before I pulled the sources for the
release build. Sorry about that. Will see if I can find time tonight and fix it.

Kind Regards,
 knut

Comment 9

[knut st. osmundsen]

Attachment: New ipluginw.dll w/ the fix.

I haven't time to test this binary (it's 3am here), but I've verified that the
fix is actually in the binary. Hope it works now.

Kind Regards,
 knut

Comment 10

[Rich Walsh]

The new one WFM.

Comment 11

[Mike Kaply [:mkaply]]

New DLL is on innotek's site and linked to from our OS/2 Mozilla site.