plugins registered using HKEY_CURRENT_USER\Software\MozillaPlugins\ tree are ignored




12 years ago
12 years ago


(Reporter: bsittler, Unassigned)


Firefox Tracking Flags

(Not tracked)



(2 attachments, 2 obsolete attachments)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070914 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070914 Firefox/

Plug-ins registered using the windows registry work if the keys are written under HKEY_LOCAL_MACHINE\Software\MozillaPlugins\ but fail if the same keys are written to under HKEY_CURRENT_USER\Software\MozillaPlugins\ instead. This disagrees with the documentation (see ) which claims both should work.

Reproducible: Always

Steps to Reproduce:
1.register a plugin using a HKEY_CURRENT_USER\Software\MozillaPlugins\ subkey
  (for example, install flash player, copy registry tree HKEY_LOCAL_MACHINE\Software\MozillaPlugins\ to HKEY_CURRENT_USER\Software\MozillaPlugins\ and then delete HKEY_LOCAL_MACHINE\Software\MozillaPlugins\ )
2.restart Firefox
Actual Results:  
note that plugin does not function and is not listed in about:plugins

Expected Results:  
plugin works normally for the user who registered it

a workaround is possible by packaging the plug-in inside a subdirectory named "plugins", writing a minimal install.rdf to the parent directory, and registering it as a Firefox Add-On using a value under HKEY_CURRENT_USER\Software\%VENDOR%\Name\Extensions (replace %VENDOR% with vendor name, of course). see for documentation of this method.

an example install.rdf:

<rdf:RDF xmlns:rdf="">
    <rdf:Description about="urn:mozilla:install-manifest" xmlns="">
        <name>Plug-In Extension</name>
Posted patch patch against firefox (obsolete) — Splinter Review
This patch is an attempt to fix the problem, however I have been unable to verify that it works as I don't yet have a working Windows build environment for Firefox/Mozilla.
this is the same patch as above, except that it includes the indentation changes. these have no effect on the functioning of the code, but make it easier to read the result (but harder to read the patch)
Forgot to mention in the original report that this bug prevents plugins installed by non-admin users on windows vista from being picked up by a subsequent Firefox installation. That is, the first install problem for plugins is not fixed in vista with UAC.
Note that the corresponding bug in WebKit was recently fixed:
fixed a bug and a compiler warning; verified that this actually works in firefox on win32
Attachment #282122 - Attachment is obsolete: true
Attachment #282125 - Attachment is obsolete: true
Component: OS Integration → Plug-ins
Product: Firefox → Core
QA Contact: os.integration → plugins
Attachment #283051 - Flags: review?(jst)
Ever confirmed: true
I'm happy to report that I somehow missed that this has already been fixed on the trunk. Here's hoping the fix makes its way to firefox branches soon...
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 293062
Comment on attachment 283050 [details] [diff] [review]
patch against firefox

+  for (rootnum = 0; rootnum < sizeof(roots)/sizeof(*roots); rootnum ++)
+  {
+    char curKey[_MAX_PATH] = "Software\\MozillaPlugins";

This could move out of the loop.

+  if (rv == NS_ERROR_FAILURE) {
+    return rv;
+  }

Use NS_FAILED(rv) instead of rv == NS_ERROR_FAILURE here.

sr=jst with that. Requesting review from rstrong as he's dealt with some related stuff lately IIRC.
Attachment #283050 - Flags: superreview+
Attachment #283050 - Flags: review?(robert.bugzilla)
Attachment #283051 - Flags: review?(jst)
Absolutely right about NS_FAILED. Also there's apparently a macro somewhere in the mozilla headers for array length (I forget the name of it just now).

As for the curKey initializer, actually you can't move that out of the loop -- the buffer is re-used by the registry enumeration, and is not left with the original contents after each run of the loop body.

To my (unexperienced) eyes, the fix already committed to the trunk for bug 293062 (of which i think this is a duplicate) is a lot simpler since it just renames the function and calls it twice with different root keys as arguments.

Anyhow, sorry to waste people's time with a duplicate bug! (a spelling difference -- MozillaPlugin vs. MozillaPlugins caused me to miss the older fixed bug in my searches)
Comment on attachment 283050 [details] [diff] [review]
patch against firefox

removing request... I think we should just go with the patch in Bug 293062 for the branch since it has baked for a while now.
Attachment #283050 - Flags: review?(robert.bugzilla)
You need to log in before you can comment on or make changes to this bug.