Multiple manifests not loaded in extension folder

RESOLVED WONTFIX

Status

()

Toolkit
Build Config
RESOLVED WONTFIX
13 years ago
13 years ago

People

(Reporter: kinger, Assigned: Benjamin Smedberg)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
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.
(Assignee)

Comment 1

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

Comment 2

13 years ago
oops, forgot to cc on the question
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?
(Reporter)

Comment 4

13 years ago
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.
(Assignee)

Comment 5

13 years ago
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?
(Reporter)

Comment 6

13 years ago
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

13 years ago
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).
(Assignee)

Comment 8

13 years ago
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

13 years ago
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. :-(
(Assignee)

Comment 10

13 years ago
> 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

13 years ago
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!
brian: maybe a better idea would be to use dynamic overlays?
http://www.xulplanet.com/ndeakin/archive/2005/2/13/
(Reporter)

Comment 13

13 years ago
(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.
(Reporter)

Comment 14

13 years ago
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.
(Assignee)

Comment 15

13 years ago
I'm going to WONTFIX this, and file a new bug on adding extension paths to the
directory service in some way.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.