Closed Bug 223238 Opened 19 years ago Closed 19 years ago

browser should add missing Windows registry key "CurrentVersion" if Java plugin is found

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: lwchk2001, Assigned: mcsmurf)

References

()

Details

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5) Gecko/20031007

1. The browser complains about missing Java plugin, though the dll's are listed
in about:config.
2. Installing Java again doesn't solve the problem.

Computer config:
Browser: Mozilla 1.5 (ZIP version only), Firebird 0.7
Java: Sun Java SDK 1.4.2_02
OS: Windows Me and XP (both)

PS: Installer version does not have this problem

Reproducible: Always

Steps to Reproduce:
1. Unzip Mozilla to e:\apps\mozilla\
2. Unzip Firebird to e:\apps\mozillafirebird\
That's a bug in the JRE/Java SDK, not Mozilla. Starting from 1.4.2, the JRE
checks for a registry key only created by the installer. Solution: 
http://www.gemal.dk/archives/000271.html
Possible dupe.
now why would you file a bug about .zip builds against the installer?
Assignee: general → peterlubczynski-bugs
Component: Installer → Plug-ins
I think the relevant dupe (for SeaMonkey anyway, there's probably another one in
the Firebird product) is bug 81240, duping bug against that. But please reopen
if you disagree/I am wrong.

*** This bug has been marked as a duplicate of 81240 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
that's nice, but we (!=xpinstall) should fix this. it's possible.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Marking this new based on timeless' comment...
Status: UNCONFIRMED → NEW
Ever confirmed: true
yeah, looks like the plugin is looking for this registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org\Mozilla]
"CurrentVersion"="1.0"

When I get around to it, I'll make a patch for nsPluginDirServiceProvider.cpp
which will add the key if missing (if allowed) if the Java plugin registry keys
are found.
Summary: Java support is broken on ZIP version of Mozilla and Firebird → browser should add missing Windows registry key "CurrentVersion" if Java plugin is found
I think you would only need to call regcreatekeyex
http://msdn.microsoft.com/library/en-us/sysinfo/base/regcreatekeyex.asp?frame=true
somewhere here
http://lxr.mozilla.org/seamonkey/source/modules/plugin/base/src/nsPluginDirServiceProvider.cpp#302.
 This function will either create the registry key and returns
REG_CREATED_NEW_KEY or will just be opened and returns REG_OPENED_EXISTING_KEY.
So i think the fix would be quite simple.
Attached patch just a try (obsolete) — Splinter Review
here is some try from me for this patch, it works at least
comments welcome (i know the patch is not very good, actually i even don't know
C++ *g*)!
Attached patch Patch v.1Splinter Review
So here is the improved version of it, thanks to biesi for his comments on my
first patch! I tested this patch as Administrator, main user and Guest on a
win2k system and it worked. If the registry key is not there, it creates it
with the version of the currently installed Mozilla version. If it is already
there, it doesn't change it.
Assignee: peterlubczynski-bugs → mcsmurf
Attachment #144402 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #144411 - Flags: review?(peterl-bugs)
Comment on attachment 144411 [details] [diff] [review]
Patch v.1

     char curKey[_MAX_PATH] = "Software\\JavaSoft\\Java Plug-in";
     char path[_MAX_PATH];
     char newestPath[_MAX_PATH + 4]; // to prevent buffer overrun when adding
\bin
+    char mozPath[_MAX_PATH] = "Software\\mozilla.org\\Mozilla";

Seems like all of those should be const char arrays, not char arrays (unless
there's something in the code that makes this not compile if those are changed
to const).

r+sr=jst
Attachment #144411 - Flags: superreview+
Attachment #144411 - Flags: review?(peterl-bugs)
Attachment #144411 - Flags: review+
Comment on attachment 144411 [details] [diff] [review]
Patch v.1

This bug causes problems for people using java with a mozilla zip build, this
patch fixes it
Attachment #144411 - Flags: approval1.7?
Comment on attachment 144411 [details] [diff] [review]
Patch v.1

a=asa (on behalf of drivers) for checkin to 1.7
Attachment #144411 - Flags: approval1.7? → approval1.7+
As far as i can see mozPath can be set to const and curKey can be set to const
when this line
      result = ::RegEnumKeyEx(baseloc, index, curKey, &numChars, NULL, NULL,
NULL, &modTime);
will be changed to
      result = ::RegEnumKeyEx(baseloc, index, (char *) curKey, &numChars, NULL,
NULL, NULL, &modTime);
Anyway i'll better ask someone who knows c++ better than me :)
Attached patch Patch variant 2Splinter Review
Attached patch Patch variant 2Splinter Review
contains changes mentioned in comment
patch variant 2 has been checked in:
2004-04-11 08:08	bmlk%gmx.de 	mozilla/ modules/ plugin/ base/ src/
nsPluginDirServiceProvider.cpp 	1.10 	10/2  	improve Java plugin operability for
win zip builds by creating the necessary registry key if it doesnt already
exist, bug 223238 patch by mcsmurf@gmx.de r/sr=jst a=asa
resolved then :)
Status: ASSIGNED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
(In reply to comment #13)
>       result = ::RegEnumKeyEx(baseloc, index, (char *) curKey, &numChars, NULL,
> NULL, NULL, &modTime);

Have you tested that this doesn't crash?

(In reply to comment #18)
> (In reply to comment #13)
> >       result = ::RegEnumKeyEx(baseloc, index, (char *) curKey, &numChars, NULL,
> > NULL, NULL, &modTime);
> 
> Have you tested that this doesn't crash?

Since this code cast away const-ness, testing it may be really hard: it may work
fine on some configurations and fail on another.

Better (and C++ Standard compliant) way is to avoid casting away const-ness at all.
(In reply to comment #18)
> (In reply to comment #13)
> >       result = ::RegEnumKeyEx(baseloc, index, (char *) curKey, &numChars, NULL,
> > NULL, NULL, &modTime);
> 
> Have you tested that this doesn't crash?

Didn't crash here, but some people told me that this is bad, also a look at MSDN
told me something like that *g*; bernd removed that const for me, the other
const stayed (that for mozPath)
*** Bug 278572 has been marked as a duplicate of this bug. ***
The recent dupe bug 278572 seems to tell that Java still does not work with us
setting this registry key, I don't know what elese we need to provide to Java
(using the installer once solved the problem for this guy).
As it seems to be a single case, I just want to note it but I don't want to
reopen this bug...
I think there is still some bug with this, yes. Mozilla would also need to write
the path to the exe in the registry to work (would need to look up the exact
registry entry in Google). I'll maybe create a patch if i have some time, but
feel free to create a patch yourself and attach it here.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.