254732 - add an option to install binary components (libraries) to app directory or system directory

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[Nickolay_Ponomarev]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040806 Firefox/0.9.1+ (best browser EVAR1!!)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040806 Firefox/0.9.1+

Some extensions need to install additional binary components into Mozilla
Firefox folder or into Windows\System32 in order to operate correctly. Using
extension.xpi/components/ is unacceptable because Windows doesn't look there for
dlls.

One such extension is DOM inspector, we're trying to package it for Thunderbird
0.7+ - see <http://forums.mozillazine.org/viewtopic.php?p=706767#706767>, - it
needs gkgfx.dll file in application directory.

What I'm asking for is that you either look for libraries/ directory in the xpi
and copy files from it to app. dir. automatically, or add a new tag in
install.rdf, like <em:library> which will mean the target file should be copied
to app. dir. on install.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Asa Dotzler [:asa]]

This is a duplicate. Please find the original and resolve this one. Thanks.

Comment 2

[Nickolay_Ponomarev]

I searched for more than 20 minutes, but I couldn't find the original. Forgive me.

Comment 3

[Asa Dotzler [:asa]]

sorry about that. I guess it was a forum discussion or mailing list discussion.
I think that the answer to this is "no" and that you are still free to use XPI
for these kinds of actions, but not EM. Ben can resolve this or accept it as a
feature request.

Comment 4

[Benjamin Smedberg]

This is WONTFIX as indicated, gkgfx should already be loaded before we get
anywhere close to DOMI (and I don't think DOMI should be linking against it
anyway). Loading dependent libraries directly from an extension directory sounds
more interesting and perhaps possible, but that's a different bug.

Comment 5

[Jens Bannmann]

(In reply to comment #4)
> Loading dependent libraries directly from an extension directory sounds
> more interesting and perhaps possible, but that's a different bug.

Benjamin, is such a bug filed already? I couldn't find it...

Comment 6

[Benjamin Smedberg]

No it isn't, and I don't particularly want it filed until somebody can show me a
potential extension that cannot be implemented sanely without it.

Comment 7

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #6)
> No it isn't, and I don't particularly want it filed until somebody can show me
> a potential extension that cannot be implemented sanely without it.

Components built with VC7 will not load properly in Firefox unless msvcp70.dll
and mscr70.dll are available for instance in the app's main directory. I just hit
the problem.

Comment 8

[Jacek]

I entirely agree with comment #6 - there is no reason to allow extensions to install anything into well known directories. The solution however is to support loading of extension depenedencies from extension directory what does not work currently, at least on win platforms ( see bug #Bug 330912).

The simplest way is to use SetDllDirectory function pointing to extension componenets directory on NT systems and adding appropriate PATH environment value on non NT systems.

Having done that there would be no need to install anything (including mscr70.dll into aplication or system directory).