Closed Bug 519708 Opened 10 years ago Closed 9 years ago

Restore OJI for OS/2 and put ipluginw back

Categories

(Core :: Plug-ins, defect, major)

1.9.2 Branch
x86
OS/2
defect
Not set
major

Tracking

()

RESOLVED WONTFIX
mozilla1.9.2

People

(Reporter: mozilla, Unassigned)

References

Details

Attachments

(2 files)

As it seems that bug 517355 is going ahead and restores OJI for MacOSX we should do the same for OS/2, so that FF 3.6 will have a usable Java plugin. For that we would also need to push ipluginw back into the tree.

(This also means that FF 3.6 will still have to be done with GCC 3.3.5, but that shouldn't be a big problem.)
This will require changes to my patch at bug 517355.  Probably not
major ones, though.

While writing it I assumed it would only get landed on OS X, so I
removed some special-casing specific to other OSes.  I also did all my
testing on OS X, and with the JEP -- so it's possible I overlooked
something that would effect Java on OS/2.

I assume the motivation for this bug is to restore Java support on
OS/2.
I'd rather not do this if we don't have to. It will require more effort and pushing more OJI-related code into the tree. The idea was just to take care of JEP and otherwise still consider OJI to be dead.
(In reply to comment #2)
> I'd rather not do this if we don't have to.

If this is happening for Mac, why not OS/2 also?  Of course, it is wholly dependent on someone actually writing a patch, which may not even happen.
Summary: Restore OJI for OS/2 and put iplugwin back → Restore OJI for OS/2 and put ipluginw back
I haven't studied what was removed in bug 485984 and what is and what is not going to be put back in bug 510035.

I thought we wait until 510035 landed and see if that is basically enough to get Java working again on OS/2, too, by only adding a line inside #ifdef XP_OS2 here and there, add the OS/2-specific plugin wrapper (ipluginw) back. This shouldn't influence behavior on the other platforms at all and code complexity only in a minor way. As us OS/2 maintainers have to do the work anyway, you shouldn't feel much of a burden.

If that's too naive, we will probably find that out quickly, and continue living without a OS/2 Java plugin on Gecko > 1.9.1.
this adds (hopefully) everything back and modifies configure/Makefiles to enable oij and building of the os2wrapper. For this draft I had to add back nsIEventhandler.idl, probably we should find a way to not add it back. The os2wrapper files were just copied from the 1.9.1 branch, modifications will be attached in a second patch
In bug517355 new interfaces were introduced for oji nsIPluginOld, nsIPluginHostOld, nsIPluginInstanceOld and nsIPluginTagInfoOld. Basically in this patch the os2wrapper files were modified by s/nsIPlugin.../nsIPlugin...Old in every occasion. While together with the other patch compilation of ipluginw.dll is possible (gcc-3.3.5), the java plugin doesn't load. Maybe the over-all exchange of the former functions against the ...Old functions is too undifferntiated or should have been done as an addition rather than an exchange. However, it should be noted that npj2.dll has hardcoded these interfaces: NS_IPLUGIN_IID NS_IPLUGININSTANCE_IID NS_IPLUGINTAGINFO_IID
Anyway, help is needed to get further.
These bits were removed from modules/plugin/base/src/nsPluginHostImpl.cpp
(now modules/plugin/base/src/nsPluginHost.cpp) in bug488042 disable XPCOM plugin loading
-      // need to get the plugin factory from this plugin.
-      nsFactoryProc nsGetFactory = nsnull;
-#ifdef XP_OS2
-      nsGetFactory = (nsFactoryProc) PR_FindFunctionSymbol(pluginTag->mLibrary, "_NSGetFactory");
-#else
-      nsGetFactory = (nsFactoryProc) PR_FindFunctionSymbol(pluginTag->mLibrary, "NSGetFactory");
-#endif
-      if (nsGetFactory && IsCompatibleExecutable(pluginTag->mFullPath.get())) {
-        rv = nsGetFactory(serviceManager, kPluginCID, nsnull, nsnull,    // XXX fix ClassName/ContractID
-                          (nsIFactory**)&pluginTag->mEntryPoint);
-        plugin = pluginTag->mEntryPoint;
-        if (plugin)
-          plugin->Initialize();
-      }
-#ifdef XP_OS2
-      // on OS2, first check if this might be legacy XPCOM module.
-      else if (PR_FindSymbol(pluginTag->mLibrary, "NSGetFactory") &&
-               IsCompatibleExecutable(pluginTag->mFullPath.get())) {
-        // Possibly a legacy XPCOM module. We'll need to create a calling
-        // vtable/calling convention wrapper for it.
-        nsCOMPtr<nsILegacyPluginWrapperOS2> wrapper =
-                       do_GetService(NS_LEGACY_PLUGIN_WRAPPER_CONTRACTID, &rv);
-        if (NS_SUCCEEDED(rv)) {
-          rv = wrapper->GetFactory(serviceManager, kPluginCID, nsnull, nsnull,
-                                   pluginTag->mLibrary, &pluginTag->mEntryPoint);
-          plugin = pluginTag->mEntryPoint;
-          if (plugin)
-            plugin->Initialize();
-        }

The patch from bug517355 that restored oji for OS X added some, but not all of this code back
I'm sure we have to add some bits of the ifdef XP_OS2 back as well, but couldn't find a proper solution yet.
Should this be WONTFIX now?
(In reply to comment #8)
> Should this be WONTFIX now?
yeah, since I've added to every readme of firefox-3.6.x that I would need help, and nobody responded and more or less no complaints in the newsgroup came up that 3.6.x doesn't support Java plugins and for firefox-4.0 there is no option at all I think there is no real interest of somebody to get this fixed.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.