247846 - Generate bin dir EM related files with -register

Status: RESOLVED FIXED

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

Description

[Eric Dorland]

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:

Comment 1

[Ali Ebrahim]

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 % mozilla.org.

Comment 2

[Adrian Reber]

I have the same problem building a rpm for firefox.

Comment 3

[Ali Ebrahim]

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.

Comment 4

[James Henstridge]

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
administrator.

If the installer called "firefox -register-extensions" (or whatever the option
gets named), then firefox would be ready to use after the install.

Comment 5

[Warren Togami]

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.

Comment 6

[Eric Dorland]

> 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.

Comment 7

[Dale]

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?

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

Resummarizing. 

Comment 9

[Alexandru Fomin]

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.

Comment 10

[Eric Dorland]

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?

Comment 11

[Ali Ebrahim]

(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
Beta.

Comment 12

[Eric Dorland]

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
installed?

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?

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

generates:
bin/extensions/*
bin/components.ini

when ./firefox -register is run

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

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.

bin/extensions/{GUID1}/install.rdf
bin/extensions/{GUID1}/chrome/foo.jar
bin/extensions/{GUID1}/components/foo.js
bin/extensions/{GUID2}/install.rdf
bin/extensions/{GUID2}/chrome/foo2.jar

... 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:
extension,{GUID1}\n
extension,{GUID2}\n
theme,{GUID3}\n

etc etc... 

NOW run ./firefox -register

this should install all your added extensions and themes in addition to the
built in ones.

Comment 15

[Dale]

does this code get shared with thunderbird?  it needs a similar fix.

Comment 16

[Eric Dorland]

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?

Comment 17

[Ryan Polk (Quark)]

setting fixed-aviary1.0 for bugfixes checked into branch, for searching purposes.
sorry for bugspam.