297094 - Multiple manifests not loaded in extension folder

Status: RESOLVED WONTFIX

(Toolkit Graveyard :: Build Config, defect)

Description

[Brian King [:kinger]]

I have an extension that pulls in widgets at runtime, and these widgets are
defined in overlays. As a matter of design, I have the overlays in many
different manifest files.

However, only chrome.manifest is recognised in the extension directory. All the
other manifest files I have in there are not loaded.

They are recognised if I put the extension and manifests in application chrome.

Comment 1

[Benjamin Smedberg]

Darin, Robert, can you think of a good reason not to allow additional manifests
in <extensiondir>/chrome/*.manifest ?

Comment 2

[Benjamin Smedberg]

oops, forgot to cc on the question

Comment 3

[Robert Strong (they/them - no direct email)]

I can't think of any reasons not to besides the additional overhead required to
enumerate *.manifest for each extension and theme directory in all locatitons
vs. always using using chrome.manifest. I also can't think of any benefit of
allowing multiple manifests besides not having to create an extension packaging
process that would create a single chrome.manifest in the case where an existing
packaging process already creates multiple manifests. Are there any other benefits?

Comment 4

[Brian King [:kinger]]

Let me explain why I need multiple manifests, and this might clarify things.

I have an extension (as yet unreleased) that has hunks of UI stored in overlays,
and are pulled in depending on (in the old days) entries in the manifest. Now
I'd like to have a manifest for each one. 

There is a settings window which let you customise this, and what it does is
deletes/generates the manifest depending on what UI was chosen. This is hacky,
but would work nicely if multiple manifests were allowed. So I'm presuming the
manifests will be read at each startup, not just after first install.

The reason it is implemented like this is because the overlays contain keys,
commands, etc that should only work if the UI item is included. So they can't be
included in the main XUL.

Comment 5

[Benjamin Smedberg]

Just for reference, how does the extension know where it is installed?

There are other ways to solve this problem in ffox 1.1 (using a directory
service provider), but I'm interested in knowing whether the extension just
blindly assumes that it's installed in <profile>/extensions/<extensionID>, which
is not alaways a correct assumption.

Perhaps we need a way for extensions to determine where they are installed?

Comment 6

[Brian King [:kinger]]

The extension has a script that "blindly assumes" that it's installed in
<profile>/extensions/<extensionID> as you say.

But I thought the install location is in the hands of the extension author, not
the user. Am I wrong?

A way for extensions to determine where they are installed would be a 'good thing'.

Comment 7

[James Ross]

I'll just point out that ChatZilla also must assume it is installed into that 
location to find and copy the application icons out of its XPI-extraction and 
into the 'right place'. I bet many other extensions do it as well.

Of course, installing icons is its own issue, but there definately needs to be 
a way to know where an extension is installed, now that there is more 
locations than just the profile (and app, but that is a very minority case for 
most extensions).

Comment 8

[Benjamin Smedberg]

I already fixed installing icons: if you place icons in
<extension>/chrome/icons/default they are automatically picked up by the trunk
widget code.

Please be aware in toolkit 1.9 that assuming <profile>/extensions/<ID> is going
to fail: I have an unfinished idea to move the extension install dir to
<profile>/extensions/<ID>/<version> at least in some cases, so that multiple
versions of the same extension can be installed simultaneously.

Comment 9

[James Ross]

I don't give a monkies if you've fixed it, we still need to do it. More 
importantly, I don't recall ever seeing anything about it, least of all 
documentation. :-(

Comment 10

[Benjamin Smedberg]

> I don't give a monkies if you've fixed it, we still need to do it. More 

You only need to do it for Firefox 1.0 (please don't do it in 1.1!).

> importantly, I don't recall ever seeing anything about it, least of all 
> documentation. :-(

http://developer-test.mozilla.org/en/docs/Bundles

Comment 11

[James Ross]

Heh, that was all written yesterday.

Assuming that Firefox has never been version 1.1 or above when it didn't work, 
we could potentially avoid it. Which means writing a version comparitor. Yay!

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

brian: maybe a better idea would be to use dynamic overlays?
http://www.xulplanet.com/ndeakin/archive/2005/2/13/

Comment 13

[Brian King [:kinger]]

(In reply to comment #12)
> brian: maybe a better idea would be to use dynamic overlays?
> http://www.xulplanet.com/ndeakin/archive/2005/2/13/

Yes, this certainly looks like the way to go when ready.

Comment 14

[Brian King [:kinger]]

After some tests, it seems that dynamic overlays solve my problem.

I'll leave it up to you guys to decide if multiple manifests are
desirable/should be allowed.

Comment 15

[Benjamin Smedberg]

I'm going to WONTFIX this, and file a new bug on adding extension paths to the
directory service in some way.