Closed Bug 247846 Opened 20 years ago Closed 20 years ago

Generate bin dir EM related files with -register


(Toolkit :: Add-ons Manager, defect, P2)






(Reporter: eric, Assigned: bugs)


(Keywords: fixed-aviary1.0)


(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7

The new extension manager is nice and all, but there are some serious
limitations if used outside of the regular firefox installer. There is no way to
generate the Extensions.rdf file without running firefox as root first as root,
which is clearly unacceptable. Their needs to be a way to generate this file
like the regxpcom and regchrome commands do. Otherwise, at least for the Debian
packages, I'll have to glue together various pieces of the Extension.rdf with a
script to generate it myself unless a better way is found. 

Reproducible: Always
Steps to Reproduce:
Flags: blocking1.0+
Eric, you shouldn't be setting blocking +/- flags, only ? flags. The Firefox
developers will then decide whether or not its +/-. Changing flag to ?.

If you really need this to create your Debian Firefox package, I suggest that
you get in touch with Ben Goodger via IRC or email at ben %
Flags: blocking1.0+ → blocking1.0?
I have the same problem building a rpm for firefox.
I'm going to confirm this bug, because it's something that we should do so that
distros can package us properly. Having said this, it doesn't need a UI, but
perhaps a command line switch or something.
Ever confirmed: true
Flags: blocking1.0? → blocking1.0+
Priority: -- → P3
Note that this probably isn't just a Linux issue.  The release notes say that
this will be a problem on any platform where users don't have write access to
the install directory.

I'd expect that a company would run into the same problems if they were trying
to roll out firefox to a large number of Windows desktops where the users
wouldn't have write access to the install directory.  While you can tell the
installer to do a silent install, it would be necessary to run firefox once as

If the installer called "firefox -register-extensions" (or whatever the option
gets named), then firefox would be ready to use after the install.
If that command can work without a terminal or X, fully automated within a
script, then that would be acceptable.  Otherwise we consider it to be a design
flaw that it is difficult/impossible to properly package.
> If the installer called "firefox -register-extensions" (or whatever the option
> gets named), then firefox would be ready to use after the install.

The switch already exists ("-install-global-extensions"), the problem is that
firefox runs and wants X running. It **** out before installing the extensions
if X is not present.
This same "bug" exists in thunderbird, is there an easy way to let the
thunderbird  developers know about this bug and possibly share code for a fix?
Priority: P3 → P2
Summary: A way to generate an Extensions.rdf file? → Generate bin dir EM related files with -register
Target Milestone: --- → Firefox1.0beta
One more observation .. from a package maintainer/sysadmin point of view, we
should make use of the -lock-item/-unlock-item option/functionality, to prevent
the de-installation of an extension/theme through the Extension/Theme Manager; 
all the installation/de-installation is(shoudl be) done through the package
manager of the system (rpm, dpkg, pkgtool, ...)

But if you lock an extension, the user is not allowed anymore to disable the
extension, if he/she doesn't wont to use it; and this is also not wanted I think.
Indeed, the locking mechinism sounds very nice, if it would allow you to disable
a locked plugin on a per user basis. 

Has this bug been resolved in the 0.9.1 release?
(In reply to comment #10)
> Has this bug been resolved in the 0.9.1 release?

No, I don't believe that it has. It's targeted for the next release, Firefox 1.0
Flags: blocking-aviary1.0RC1+
Alright, I don't mean to turn this into my private Q&A, but I'm still confused
about where extensions should be installed. it appears they should be installed
in defaults/profile/extensions not into extensions. This means that when I new
profile is created, those files are installed as well. What happens if later on
those files are removed? Does the profile believe the extensions are still

Should the extensions be installed in the extensions directory instead? What
exactly is the relationship between the installed-extensions.txt and the
installed-extensions-processed.txt files?
Attached patch patchSplinter Review

when ./firefox -register is run
OK, patch checked in branch and trunk. 

To make a Firefox distribution with no extensions:

Build firefox, strip any files you don't need from the bin dir, then run:
./firefox -register

To make a Firefox distribution with extensions:

** after the build phase but before running ./firefox -register **
create folders in bin/extensions for the installed extensions, e.g.


... etc or whatever the structure of the extensions look like when their XPI
files are unpacked. Make sure the install.rdf files are there. The folder names
must match the GUIDs from the install.rdf files.

Now echo into installed-extensions.txt:

etc etc... 

NOW run ./firefox -register

this should install all your added extensions and themes in addition to the
built in ones.
Closed: 20 years ago
Resolution: --- → FIXED
does this code get shared with thunderbird?  it needs a similar fix.
This patch doesn't actually apply to 0.9.1. Have other things changed in CVS
that affect this patch, or can I try to apply it by hand?
setting fixed-aviary1.0 for bugfixes checked into branch, for searching purposes.
sorry for bugspam.
Keywords: fixed-aviary1.0
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.