Closed Bug 397318 Opened 17 years ago Closed 17 years ago

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

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 293062

People

(Reporter: bsittler, Unassigned)

Details

Attachments

(2 files, 2 obsolete files)

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>
Attached patch patch against firefox 2.0.0.6 (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: http://bugs.webkit.org/show_bug.cgi?id=15053
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
Attachment #282125 - Attachment is obsolete: true
Component: OS Integration → Plug-ins
Product: Firefox → Core
QA Contact: os.integration → plugins
Attachment #283051 - Flags: review?(jst)
Status: UNCONFIRMED → NEW
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...
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
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)
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 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)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: