The default bug view has changed. See this FAQ.

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

RESOLVED DUPLICATE of bug 293062

Status

()

Core
Plug-ins
RESOLVED DUPLICATE of bug 293062
10 years ago
10 years ago

People

(Reporter: Benjamin C. Wiley Sittler, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

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 http://developer.mozilla.org/en/docs/Plugins:_The_first_install_problem ) 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 http://developer.mozilla.org/en/docs/Adding_Extensions_using_the_Windows_Registry for documentation of this method.

an example install.rdf:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description about="urn:mozilla:install-manifest" xmlns="http://www.mozilla.org/2004/em-rdf#">
        <id>{d5bc46d8-67c7-11dc-8c1d-00123456789a}</id>
        <version>0.0.0.1</version>
        <targetApplication>
            <rdf:Description>
                <id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</id>
                <minVersion>1.0</minVersion>
                <maxVersion>3.0.0.*</maxVersion>
            </rdf:Description>
        </targetApplication>
        <name>Plug-In Extension</name>
    </rdf:Description>
</rdf:RDF>
(Reporter)

Comment 1

10 years ago
Created attachment 282122 [details] [diff] [review]
patch against firefox 2.0.0.6

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

Comment 2

10 years ago
Created attachment 282125 [details] [diff] [review]
same patch, but including indentation changes

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

Comment 3

10 years ago
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.
(Reporter)

Comment 4

10 years ago
Note that the corresponding bug in WebKit was recently fixed: http://bugs.webkit.org/show_bug.cgi?id=15053
(Reporter)

Comment 5

10 years ago
Created attachment 283050 [details] [diff] [review]
patch against firefox 2.0.0.7

fixed a bug and a compiler warning; verified that this actually works in firefox 2.0.0.7 on win32
Attachment #282122 - Attachment is obsolete: true
(Reporter)

Comment 6

10 years ago
Created attachment 283051 [details] [diff] [review]
same patch, but including indentation changes
Attachment #282125 - Attachment is obsolete: true

Updated

10 years ago
Component: OS Integration → Plug-ins
Product: Firefox → Core
QA Contact: os.integration → plugins
(Reporter)

Updated

10 years ago
Attachment #283051 - Flags: review?(jst)
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 7

10 years ago
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...
(Reporter)

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 293062
Comment on attachment 283050 [details] [diff] [review]
patch against firefox 2.0.0.7

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

Updated

10 years ago
Attachment #283051 - Flags: review?(jst)
(Reporter)

Comment 10

10 years ago
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 2.0.0.7

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.