Mozilla should read HKEY_CURRENT_USER\Software\MozillaPlugin




14 years ago
12 years ago


(Reporter: cworm1976, Assigned: emaijala+moz)


Windows XP
Bug Flags:
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



14 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; da-DK; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Mozilla looks at HKEY_LOCAL_MACHINE\Software\MozillaPlugin for plugins. 
However, it should also look at HKEY_CURRENT_USER\Software\MozillaPlugin. This 
will allow users who do not have administrator privileges to install their own 
plugins. Also, this is suggested on from which 
I cite here:

"If the key cannot be created under HKEY_LOCAL_MACHINE, create it as 
HKEY_CURRENT_USER\Software\MozillaPlugins\ under HKEY_CURRENT_USER. On Windows 
XP and Windows 2000, in order to write to the registry, sometimes the software 
may need Administrator privileges. Thus, some installers may need to write to 
the HKEY_CURRENT_USER key; this doesn't require Administrator privileges. 
Traditionally, HKEY_CURRENT_USER is a copy of everything in 

It is the file modules/plugin/base/src/nsPluginDirServiceProvider.cpp that 
should be updated.

Finally, if a plugin is registered under both HKEY_LOCAL_MACHINE and 
HKEY_LOCAL_USER the one registered under HKEY_LOCAL_USER should take 

Reproducible: Always

I only looked at firefox (bad me).

*** This bug has been marked as a duplicate of 126659 ***
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE

Comment 2

14 years ago
This is a different issue: Bug 126659 is that changing the key 
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla 0.9.8+\Extensions\Plugins to some 
directory does not make Mozilla look in that directory. And as mentioned in 
the comments to the bug it is not clear that bug 126659 is even a bug.

The presnt bug is that mozilla only looks in 
HKEY_LOCAL_MACHINE\Software\MozillaPlugin for plugins while it should also 
look in HKEY_CURRENT_USER\Software\MozillaPlugin (according to
Resolution: DUPLICATE → ---
Assignee: general → nobody
Component: General → Plug-ins
Product: Mozilla Application Suite → Core
QA Contact: general → plugins
Version: unspecified → Trunk
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Ever confirmed: true

Comment 4

13 years ago
This BUG still seems to exist in Firefox 1.5.
Are there any plans to fix it?

Comment 5

12 years ago
This bug continues to exists in Firefox 2.0.

The "specification" here:
implies that the HKEY_CURRENT_USER hive will be checked in addition to the HKEY_LOCAL_MACHINE. 

We can see in nsPluginDirServiceProvider.cpp::GetPLIDDirectories that only the HKEY_LOCAL_MACHINE is checked. 

I agree with the original poster that the expected operation is that the HKEY_CURRENT_USER hive should take precedence over the HKEY_LOCAL_MACHINE if a key is found in both.


12 years ago
Assignee: nobody → emaijala


12 years ago

Comment 6

12 years ago
Posted patch Patch v1 (obsolete) — Splinter Review
Here's a patch with slight additional cleanup.
Attachment #258931 - Flags: superreview?(roc)
Attachment #258931 - Flags: review?(neil)
Comment on attachment 258931 [details] [diff] [review]
Patch v1

>-#include "nsCOMArray.h"
I was wondering about this, but then I twigged later ;-)

>+  nsresult rv = GetPLIDDirectoriesWithHKEY(HKEY_LOCAL_MACHINE, &dirs);
>+  NS_ENSURE_SUCCESS(rv, rv);
>+  // This can fail for HKEY_CURRENT_USER if the key doesn't exist
>+  GetPLIDDirectoriesWithHKEY(HKEY_CURRENT_USER, &dirs);
Two points:
1. I think (but have no way to tell) you want to check user then machine
2. I think failure is unremarkable for either root, please check both roots

>+nsPluginDirServiceProvider::GetPLIDDirectoriesWithHKEY(HKEY aKey, nsCOMArray<nsILocalFile> *aDirs)
Two points:
1. The declaration got lost from the .h file (accidentally trimmed?)
2. I'm not convinced about *aDirs, I think perhaps &aDirs is better
   (think about (*aDirs)[i])

>+#include "nsCOMArray.h"
>+#if defined (XP_WIN)
>+#include <windows.h>
The nsCOMArray.h could be XP_WIN too.
Attachment #258931 - Flags: review?(neil) → review-

Comment 8

12 years ago
Comment on attachment 258931 [details] [diff] [review]
Patch v1

(In reply to comment #7)
> Two points:
> 1. I think (but have no way to tell) you want to check user then machine

Why would the order be important? The result is just a list of directories.

Thanks for the comments, I'll fix the patch.
Attachment #258931 - Attachment is obsolete: true
Attachment #258931 - Flags: superreview?(roc)
The order matters because it will affect the order in which plugins get searched, right? E.g. if there are multiple plugins that want to handle the same content type.

Comment 10

12 years ago
Posted patch Patch v1.1Splinter Review
Ok, here is a less tired patch with fixed order and other improvements.
Attachment #259524 - Flags: superreview?(roc)
Attachment #259524 - Flags: review?(neil)
Comment on attachment 259524 [details] [diff] [review]
Patch v1.1

>       if (ERROR_SUCCESS == ::RegQueryValueEx(keyloc, "Path", NULL, &type,
>-                                             (LPBYTE)&path, &pathlen)) {
>+                                            (LPBYTE)&path, &pathlen)) {
>         nsCOMPtr<nsILocalFile> localFile;
>         if (NS_SUCCEEDED(NS_NewNativeLocalFile(nsDependentCString(path),
>-                                               PR_TRUE,
>-                                               getter_AddRefs(localFile))) &&
>+                                              PR_TRUE,
>+                                              getter_AddRefs(localFile))) &&
>             localFile) {
I forgot to point this out before but these indentation changes don't belong.

>+        ::RegCloseKey(keyloc);
>       }
>-      ::RegCloseKey(keyloc);
This is wrong because now a key without a Path value doesn't get closed.

r=me if you revert the above changes.
Attachment #259524 - Flags: review?(neil) → review+
Attachment #259524 - Flags: superreview?(roc) → superreview+

Comment 12

12 years ago
Checked in to trunk with the goofs pointed out by Neil fixed.
Last Resolved: 14 years ago12 years ago
Resolution: --- → FIXED
Duplicate of this bug: 397318
Flags: wanted1.8.1.x+
You need to log in before you can comment on or make changes to this bug.