Closed Bug 284825 Opened 20 years ago Closed 19 years ago

Request to change Mozilla's method to look for Java Plugin

Categories

(Core Graveyard :: Plug-ins, defect, P1)

x86
Windows XP

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8beta2

People

(Reporter: danielle.pham, Assigned: jst)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)

We'd like to request change to the current way that Mozilla/Firefox is
looking for Java Plugin on windows.

Currently, in modules/plugin/base/src/nsPluginDirServiceProvider.cpp, mozilla
looks for Java Plugin by:
- Search in HKLM/Software/JavaSoft/Java Plug-in
- Iterate through the listed versions to search for latest installation version
of Java Plugin.  The latest plugin found is the one to recognize.

This poses several problems for us:
1) HKLM/Software/JavaSoft/Java Plug-in/ will be obsoleted starting with 6.0 Java
(a.k.a 1.6.0 or Mustang).
This registry branch was there due to historic reason when Java Plugin was
bundling separately from JRE.
Since 1.4.X, Java Plugin had been bundled with JRE.  We are in the process of
cleaning up Java registries
to avoid maintenancing problem due to redundant-registry dependencies in codes.

2) There is a need for multiple versions of JRE to co-exist on the same system.
 Java user should be able to
select different JRE to run with their application/applets, not just the latest
version installed on the system.

In order to avoid these problem, we'd like to request change to Mozilla's JPI
search method to:
1) Search in HKLM/Software/JavaSoft/Java Runtime Environment
2) Look for key "BrowserJavaVersion" under this location.  If this key is
defined and hold a "valid" Java version number, that should be the version for
browser to recognize.
3) If "BrowserJREVersion" is not defined or does not hold a "valid" version
number, fall back to look for latest
installation version of Java Runtime.

In (2) and (3), "valid" version means:
- a subtree of that version under HKLM/Software/JavaSoft/Java Runtime exists
- this subtree contains JavaHome key.

We'd like to request this change in Mozilla 1.8 and Firefox 1.1 (in June?) to
sync intime with our schedule for 6.0 Java.
 

Reproducible: Always
Assignee: general → jst
Status: UNCONFIRMED → NEW
Component: General → Plug-ins
Ever confirmed: true
Product: Mozilla Application Suite → Core
Target Milestone: --- → mozilla1.8beta2
Version: unspecified → Trunk
Severity: blocker → major
Status: NEW → ASSIGNED
Flags: blocking-aviary1.1?
Priority: -- → P1
This patch changes the current logic to search java plugin in windows registry
to make mozilla flexible and compatible with the future Java
Comment on attachment 178187 [details] [diff] [review]
the patch checks  BrowserJavaVersion in Windows Registry

r+sr=jst
Attachment #178187 - Flags: superreview+
Attachment #178187 - Flags: review+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
And thanks for the patch! :)
Thanks Johnny! BTW, which version of Firefox will include this patch ?
This will be included in the upcoming 1.1 (due out this summer).
Flags: blocking-aviary1.1?
These changes make the plugin code even more incompatible with the IBM Java
plugin than they were before.

Why is there so much special code required for the Sun Java plugin?
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: