479024 - Add ability to use NPRuntime-based IBM Java Plug-In

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Anup M]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre)

Note: This issue is similar to Bug 406040 except that it needs to be addressed from the IBM perspective.
i.e.https://bugzilla.mozilla.org/show_bug.cgi?id=406040

For several months a new implementation of the Java Plug-In has been under
development which uses the NPAPI and NPRuntime plugin and scripting mechanisms
rather than the archaic OJI. This work has been done in close cooperation with
Mozilla.org and several browser-side changes were needed in order to enable a
non-OJI Java Plug-In. This work was done in the Firefox 3 train, so the new
plug-in currently works only on Firefox 3.

Now we at IBM has ported the new 6u10 Java code from Sun in our code stream and 
have a similar mechanism to switch between using the old and new Java Plug-Ins in the Java Control Panel. 
However, the only knobs we have available affect the plug-in used for both Firefox 2 and Firefox 3, because the Firefox browser contains the logic for searching the installed JREs on Windows and finding the Java Plug-In.

Now I believe a patch has been created in the Firefox train through Bugzilla 406040 which addresses this issue of finding the new plugins by the Firefox3 browser through the registry way.

The similar patch is needed from the IBM perspective which is having the same folder structure as Sun except for the registry keys.
IBM registry keys are addressed as   HKLM/Software/IBM  unlike 
in Sun which are addreseed as HKML/Software/JavaSoft

This is important because without the patch from the Mozilla team we will not be able to run the functionality of Firefox 3 on new plugins which will prove to be a major limitation .

Pls feel free ping me anytime for any queries and clarifications needed.

Reproducible: Always

Steps to Reproduce:
1.NA
2.
3.
Actual Results:  
New Java Plug-In can be used for FF 3 while old can be used for FF 2.--IBM perspective.

Comment 1

[Johnny Stenback (:jst)]

We'd be happy to accept a patch that does the lookup of the appropriate registry keys etc to make the new IBM Java plugin work as well. We're getting close to the end of our Firefox 3.1 cycle, but a patch is provided quickly I will do what I can to include it in Firefox 3.1 when it ships (feel free to email me directly for faster replies). Getting such a change into Firefox 3.0 is a separate battle, so lets treat that separately for now.

Comment 2

[Anup M]

To our understanding this patch needs to be provided by the bugzilla team since the change has to be made in the Firefox code base.
Pls refer 406040 on the patches created by the mozilla team.

Based on these changes made the Firefox browser will then henceforth work here 
with the new plugins.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

The patch for bug 406040 was provided by a Sun engineer. You'll need to decide which registry key you're going to use to indicate that the new plugin should be used, so it only makes sense for you to provide the patch.

Comment 4

[Johnny Stenback (:jst)]

Anup, we'd gladly take a fix for this for Firefox 3.1, but we won't hold the release only for this issue. Please see Gavin's comment above, given that it should be trivial for you guys to provide a patch that does what you want. If a patch is provided soon enough, please mark the patch approval-1.9.1? once it's been reviewed.

Comment 5

[Vinutha]

We have the changes required to the Firefox code base to make it work for IBM Java-plugin too, but we are facing problems building it . It seems to require quite some tools ,as mentioned in the following link .

https://developer.mozilla.org/En/Windows_Build_Prerequisites .

Is the above link the right one that we need to follow ?

Also considering the issues having a build setup, if we could pass on the modified files to you, would it be possible from your end to build it , so that we can verify the changes indeed work as expected.

Comment 6

[Johnny Stenback (:jst)]

(In reply to comment #5)
> We have the changes required to the Firefox code base to make it work for IBM
> Java-plugin too, but we are facing problems building it . It seems to require
> quite some tools ,as mentioned in the following link .
> 
> https://developer.mozilla.org/En/Windows_Build_Prerequisites .
> 
> Is the above link the right one that we need to follow ?

Yes, that's the right steps to follow. Everything you need is available for free.

> Also considering the issues having a build setup, if we could pass on the
> modified files to you, would it be possible from your end to build it , so that
> we can verify the changes indeed work as expected.

I would recommend you try it out yourself, but if that's hard for you to do for some reason you can attach a patch to this bug and request that I, or anyone else with access, pushes it through our try server system which would generate builds for you to test on.

Comment 7

[Vinutha]

Attachment: The patch contains the changes to make IBM Java plugins work with Firefox 3

Comment 8

[Vinutha]

I am attaching a patch ,with the changes required to make the IBM Java plugins
work as well, with the firefox 3 browser. 
   Would it be possible from your end to generated a test build with the
changes, so that we could test it and confirm it indeed works fine ?

Comment 9

[Vinutha]

It would be really great if you could you let us know , when we can get a test build with the above patch integrated ? In case there are any other issues ( with the patch or so )please let us know .

Comment 10

[Kenneth Russell]

As a Sun employee and the architect of the new Java Plug-In which IBM is apparently rebranding as the "IBM Java Plug-In", I find two things about this patch objectionable. The first is that if both the Sun JRE and IBM JRE are installed, the IBM JRE is preferred. I see no evidence that IBM has added any substantial value in their version that would warrant preferential treatment. The second is that the way the IBM JRE is preferred is that apparently their installer overwrites registry keys written by the Sun installer (specifically the dynamic CLSID which is tested in the function "IsAssociatedIBMkey" in the patch). This is both unnecessary and highly dubious, at least for the purpose of integrating the "IBM Java Plug-In" into Firefox.

Comment 11

[Josh Aas]

I don't see a reason to prefer the IBM plugin either. I'd prefer not having to do anything special for anyone because it leads to situations like this, but I don't know how feasible that is.

Johnny, thoughts?

Comment 12

[Vinutha]

1 . Cases where both Sun and IBM JRE are installed:

The  JRE selected is based on which the plugin is associated with.  That happens through the check in the IsAssociatedIBMkey() function, where we check the dynamic CLSID  to check which JRE is currently associated with it -  IBM or SUN's and use corresponding registry entries  there on . So I don't feel here , any JRE is being preferred.  

2. Regarding registries being overwritten. If IBM is installed first and  sun next , SUN overwrites IBM entries and vice versa. So that is the expected behaviour . 

3. Also, I believe these changes in any way will not  break the functionality from Sun perspective because, we would be only adding the code required to   check which JRE it  is currently associated with and pick those registries instead of statically looking for only Sun registries every  time .

Please let us know in case there are any other concerns .

Comment 13

[Kenneth Russell]

The Sun JRE installer does not overwrite any "IBM entries" in the registry. The dynamic CLSID (8AD9C840-044E-11D1-B3E9-00805F499D93) was defined by Sun for the Java Plug-In. IBM's overwriting of this registry entry in their JRE installer is highly suspect.

To allow Firefox to choose between multiple Java Plug-In implementations, both companies should collaborate to define some neutral registry entry or entries that would allow Firefox to discover the Java Plug-In -- for example, \\HKLM\SOFTWARE\Mozilla\Firefox\Java Plug-In, or a list of such entries (Java Plug-In 1, Java Plug-In 2, ...). Sun would require time to release a JRE update which would write this registry entry or entries during installation; it would be best if Firefox would use the current search logic if this key was not set. Firefox could present a dialog box allowing the user to choose among the available options. Another possibility would be to have the various Java Control Panel implementations incorporate this switching functionality.

I don't have a solution for toggling between Java Plug-In implementations for IE. Perhaps the Java Control Panel suggestion above would be the best option.

Comment 14

[Matthias Versen [:Matti]]

We have a RFE for a plugin manager for choosing conflicting plugins but that is however not implemented at moment.
The best solution would be a registry key that both installations are using and which is written during the installation -> the last one wins. You can add a switch in the Java Control panel to overwrite this key outside of the installation and make the own JRE the default again.

Comment 15

[Kenneth Russell]

What is Mozilla's opinion on a string registry entry \\HKLM\SOFTWARE\Mozilla\Firefox\Java Plug-In ?

What would happen if a JRE were installed first and then Firefox installed over it? Would a key like that be preserved, or would it be overwritten by Firefox's installer? What about during Firefox uninstallation? Does it completely delete the tree under \\HKLM\SOFTWARE\Mozilla\Firefox, or only selective keys?

Comment 16

[Vinutha]

I think it would be great if we could have the registry key as mentioned above. That would add the required flexibility. Could mozilla give it's view on the same?

Comment 17

[Calvin Cheung]

What's the status on this?
Is IBM going go deliver a java plugin for Firefox 3?
If not, this bug should be closed.

Otherwise, can someone from mozilla take a look at the suggestion by Ken in comment #13 and also answer the questions in comment #15?

Comment 18

[hao.dong]

setting PLIDs under \\HKLM\Software\MozillaPlugins seems to be good future directions (https://developer.mozilla.org/en/Plugins/The_First_Install_Problem). But it does not solve the mimetype conflicts for existing contents that use only <applet>, <embed> tags. Would Mozilla implement the plugin manager for such conflicts after the current java plugin lookup code is removed?

Comment 19

[Josh Aas]

We are working on this and will explain our proposal soon.

Comment 20

[Josh Aas]

We'd like to move to a system that does not prefer any particular vendors as MIME type handlers as quickly as possible. To that end we are announcing that we will be removing code that specifically looks for Sun's Java plugin in Firefox 4.0. Sun's Java plugin will have to be installed just like any other plugin. This process is described here:

https://developer.mozilla.org/en/Plugins/The_First_Install_Problem

We have been in contact with Sun about this and we recommend the same process to IBM. We have decided not to take the IBM patch here in the mean time, as adding another preferred vendor only complicates a situation we are trying to do away with entirely. In order to use the IBM plugin users will have to disable the Sun plugin if it is installed, using the Firefox Addons manager.

Another step we are taking to normalize the Java plugin situation is described in Mozilla bug 506985. We are removing the "Disable Java" preference from Firefox, users can manage Java availability using the Addon manager, just like for any other plugin. This change may make it into Firefox as soon as version 3.6.

A common question is what happens when there are two plugins installed that handle the same MIME type, a situation which would occur if both Sun and IBM Java plugins are installed. The answer is that the result is practically random but consistent across runs for any particular user. A MIME handler is selected based on the order in which plugins are loaded. The details are unimportant unless one is trying to game the system. Whichever plugin is selected to handle a MIME type, that plugin will be used for all instances of that MIME type, so long as the plugin loading order does not change.