Closed Bug 223238 Opened 19 years ago Closed 19 years ago
browser should add missing Windows registry key "Current
Version" if Java plugin is found
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.
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*)!
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
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 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 :)
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 firstname.lastname@example.org r/sr=jst a=asa
resolved then :)
Status: ASSIGNED → RESOLVED
Closed: 19 years ago → 19 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.
You need to log in before you can comment on or make changes to this bug.