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.
Darin, Robert, can you think of a good reason not to allow additional manifests in <extensiondir>/chrome/*.manifest ?
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?
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.
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?
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'.
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).
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.
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. :-(
> 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
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/
(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.
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.
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.