126659 - Mozilla doesn't load plugins from directory specified by Extensions\Plugins

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Henrik Gemal]

I modified the "Plugins" key under:
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla 0.9.8+\Extensions
to be:
C:\Program Files\Plugins
Now I've put my plugins into this directory.

But Mozilla doesn't load my plugins! Mozilla doesn't seem to support changing
the reg key...

The installer create this reg key so that external developers know where to put
the plugins, but something seems to be wrong.

Comment 1

[Peter Lubczynski]

strange....it's working for some embedding vendors

Todd, did you have to do anything special to move this?

Comment 2

[Henrik Gemal]

I've try to change both:
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla 0.9.8+\Extensions\Plugins
HKEY_CURRENT_USER\Software\Mozilla\Mozilla 0.9.8+\Extensions\Plugins
to "C:\Program Files\Plugins"
and it just doesn't work.

It's kind of bad since the Shockwave installer installs into:
C:\Program Files\Plugins
because it detects the "\Extensions\Plugins" reg key but then the Shockwave
installer completions doesn't work since the Shockwave start plugin isn't found...

Comment 3

[Henrik Gemal]

NSPR logging produces this:
0[344170]: nsPluginHostImpl::ScanPluginsDirectory dir=C:\Program 
files\mozilla.org\mozilla\plugins
0[344170]: nsPluginHostImpl::ScanPluginsDirectory dir=C:\Program 
Files\Netscape\Communicator\Program\Plugins

nothing about
"C:\Program Files\Plugins" so basiclly the plugin code needs to be aware of the 
reg.db key

Comment 4

[Peter Lubczynski]

Could the NS_APP_PLUGINS_DIR key be setup to read it's value from the Windows
registry in
http://lxr.mozilla.org/mozilla/source/xpcom/io/nsAppFileLocationProvider.cpp#182
or should a new key be defined?

Comment 5

[Conrad Carlen (not reading bugmail)]

NS_APP_PLUGIN_DIR has been defined for some time and changing its definition at
this point would not be right. Instead, I would add this location to
NS_APP_PLUGINS_DIR_LIST. Or, if C:\Program Files\Plugins is an OS-standard
location, add it to NS_OS_PLUGINS_DIR_LIST. Since we have 3 directory service
keys to define plugin locations and 2 of them are expandable lists, safe to say
we don't need to define new keys.  

Comment 6

[Daniel Veditz [:dveditz]]

In some senses I think this bug is a misunderstanding (that is, INVALID), though
perhaps it's turning into a feature request. The location published in the
registry is telling the world where we look for plugins, for the benefit of 3rd
party installs. Changing the registry doesn't change where we look, it's simply
lying to everyone else.

Comment 7

[TaylorToddK]

Implementing the nsIDirectoryServiceProvider2::GetFiles method will allow the 
browser to specify the which directories it wants to scan in from.   As Dan 
said, the registry information is provided soley for vendors and not the 
browser.  The browser does not have any code that ties itself to the registry 
info, and must be specified with one of the directories.

Dan: Not sure where xpi stands for embedded browsers atm, but this bug brings 
to mind a question.  My hypothetical situation would be where the browser 
supports multiple plug-in directories, and uses one as a "shared" directory for 
all copies of the browser on the machine.  If the xpi installer is not just a 
native installer wrapper but needs to determine the plugin location to install 
to, how will xpi determine which one of the directories the browser wants to 
use for vendor installs?

Comment 8

[TaylorToddK]

Yeck, very obfuscated. The question, simply stated is, does the embedded xpi 
allow the browser to specify which directory it wants plugins installed to?

Comment 9

[TaylorToddK]

Going back to Peter's comments, would it be possible to support a feature like 
this with a new definition?  The registry info has the problem of having to be 
under unique keys, which might become an issue the browser installer has to 
deal with.  The registry to browser relationship could be one to one or one to 
many, making it more difficult to have predefined code logic determining which 
reg key to use.

Comment 10

[Daniel Veditz [:dveditz]]

Currently a xpi script using getFolder("Plugins") gets the
NS_OS_CURRENT_PROCESS_DIR with "plugins" tacked on. As part of bug 105087 this
is getting changed to use NS_APP_PLUGIN_DIR, which I understand embedding
clients can/do override.

If someone wants to point us somewhere else that's fine, or we could even add an
additional target if it's important that script writers have the choice of an
application-specific plugin dir and some shared global one.

Comment 11

[Peter Lubczynski]

-->taking bug

This is part of the plug-in manager work.

Comment 12

[Peter Lubczynski]

--->serge
plug-in manager work

Comment 13

[rubydoo123]

plug-in branch work

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

*** Bug 293062 has been marked as a duplicate of this bug. ***