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

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Leung Wing Chung]

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\

Comment 1

[Stephan Grossklass]

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.

Comment 2

[timeless]

now why would you file a bug about .zip builds against the installer?

Comment 3

[Jon Henry]

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 ***

Comment 4

[timeless]

that's nice, but we (!=xpinstall) should fix this. it's possible.

Comment 5

[Jon Henry]

Marking this new based on timeless' comment...

Comment 6

[Peter Lubczynski]

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.

Comment 7

[Frank Wein [:mcsmurf]]

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.

Comment 8

[Frank Wein [:mcsmurf]]

Attachment: just a try

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*)!

Comment 9

[Frank Wein [:mcsmurf]]

Attachment: Patch v.1

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.

Comment 10

[Johnny Stenback (:jst)]

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

Comment 11

[Frank Wein [:mcsmurf]]

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

Comment 12

[Asa Dotzler [:asa]]

Comment on attachment 144411 [details] [diff] [review]
Patch v.1

a=asa (on behalf of drivers) for checkin to 1.7

Comment 13

[Frank Wein [:mcsmurf]]

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 :)

Comment 14

[Frank Wein [:mcsmurf]]

Attachment: Patch variant 2

Comment 15

[Frank Wein [:mcsmurf]]

Attachment: Patch variant 2

contains changes mentioned in comment

Comment 16

[Frank Wein [:mcsmurf]]

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 [e-mail] r/sr=jst a=asa

Comment 17

[Frank Wein [:mcsmurf]]

resolved then :)

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #13)
>       result = ::RegEnumKeyEx(baseloc, index, (char *) curKey, &numChars, NULL,
> NULL, NULL, &modTime);

Have you tested that this doesn't crash?

Comment 19

[Kamil Burzynski]

(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.

Comment 20

[Frank Wein [:mcsmurf]]

(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)

Comment 21

[Robert Kaiser]

*** Bug 278572 has been marked as a duplicate of this bug. ***

Comment 22

[Robert Kaiser]

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...

Comment 23

[Frank Wein [:mcsmurf]]

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.