JDK-6635585 : Modify plug-in switching mechanism to better support Firefox
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2007-11-29
  • Updated: 2010-09-08
  • Resolved: 2008-01-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10 b09Fixed
Related Reports
Relates :  
JDK-6606277 - Control panel work for new Java Plug-In
Relates :  
JDK-6682408 - DT plugin for Firefox is disabled when new plug-in is enabled
Description
In discussions with Mozilla.org it may not be possible to get them to backport the necessary changes from Firefox 3 to make the new Java Plug-In run on top of Firefox 2.

As an alternate solution, we would like to be able to turn on the new Java Plug-In for Firefox 3, while continuing to use the old one for Firefox 2. In order to enable this functionality, changes on the browser side are needed. Mozilla bug 406040 has been filed, and a patch supplied: https://bugzilla.mozilla.org/show_bug.cgi?id=406040 . We are waiting for a response from Mozilla.org regarding the integration of this patch.

Once it is integrated, we will need to change the switching mechanism between the old and new plug-ins. We will need to stop moving files around on the local disk when toggling the switch. The only change will be the setting of the UseNewJavaPlugin registry key. The "unused_plugin" directory will be renamed to "new_plugin", and the only DLL that will be built into that directory will be npjp2.dll. Changes are necessary to the bootstrapping code of the new plug-in to handle the fact that npjp2.dll is being loaded out of a subdirectory of the JRE's bin directory. The installer will need to be modified to put a copy of msvcr71.dll alongside npjp2.dll in the new_plugin directory. The latter should be done as code in the installer rather than bundling a completely separate copy of this DLL into the bundles.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6635585.2
04-12-2007
EVALUATION The goal of these changes is to allow the old plug-in to remain the default in Firefox 2, while allowing the new plug-in to be the default in Firefox 3. Changes were checked in to Firefox 3 under https://bugzilla.mozilla.org/show_bug.cgi?id=406040 to support this. These are the necessary changes on our side to complete the work. The unused_plugin directory (on Windows) has been removed and replaced with a "new_plugin" directory. The only DLL we build into it is npjp2.dll, the new plug-in for Firefox 3. Firefox knows about the existence of the UseNewJavaPlugin registry key and the new_plugin subdirectory, and changes where it scans for the Java Plug-In appropriately. We place a copy of msvcr71.dll in that directory to allow the system to find it when the browser loads npjp2.dll. This change simplifies the switching logic in ssvagent.exe drastically, since no files need to be moved around on disk any more. The bootstrapping and library loading logic for the new plug-in were adjusted to understand the presence of the new_plugin directory. Tested by installing JRE bundle and testing Firefox 2, Firefox 3 (latest nightly build) and Internet Explorer 7 both with and without the new plug-in as the default. When the new plug-in is the default, FF 2 uses the old plug-in, while FF 3 and IE 7 use the new plug-in. When the old plug-in is the default, all three browsers use the old plug-in. No other test case due to difficulty.
04-12-2007