If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

XULRunner apps need a way to override the default theme

RESOLVED INVALID

Status

()

Toolkit
Add-ons Manager
RESOLVED INVALID
11 years ago
9 years ago

People

(Reporter: Ben Turner (not reading bugmail, use the needinfo flag!), Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

The firefox default theme uuid is hardcoded into the extension manager

http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#132 

If XULRunner apps follow the firefox method for supplying a default theme (i.e. adding a single install.rdf to the extensions/{uuid} subdir and placing the theme.jar and theme.manifest in the chrome/ subdir) then the extension manager complains in upgradeThemeChrome:

http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#1648

This happens because the function is looking to upgrade contents.rdf files to the new chrome.manifest format. If neither a contents.rdf nor a chrome.manifest file are present then the extension is marked to be uninstalled. This function returns early for the default theme based on a simple test against the firefox uuid.

I see two workarounds at the moment:

The first is to include a blank chrome.manifest file alongside the install.rdf in extensions/{uuid}. This seems like an ugly hack.

The second is to copy the firefox uuid and make that be the theme's uuid. I don't know exactly how I feel about lots of XULRunner apps with default theme uuids that exactly match firefox's, but whatever. This works if you only plan on including a single theme via chrome. This doesn't work if you plan to bundle several themes with the app (which we are trying to do).

Obviously there can only be one default theme but it would be nice to have a way to inform EM that any number of bundled themes are living in the chrome/ dir while still having entries in the theme manager list. I briefly thought that the appManaged attribute would do this for me but it doesn't look like this will work atm. Could we extend the appManaged attribute to cover this as well? Or should we just stick with packaging any additional themes as extensions?
You can include additional themes that include a chrome.manifest in the appdir's extensions directory. The hack is actually having the default theme that is located in the chrome dir having an install.rdf in the extensions directory so it will be displayed in the add-ons mgr.

Also see Bug 287038.
(In reply to comment #1)
> You can include additional themes that include a chrome.manifest in the
> appdir's extensions directory. The hack is actually having the default theme
> that is located in the chrome dir having an install.rdf in the extensions
> directory so it will be displayed in the add-ons mgr.
> 
> Also see Bug 287038.

So (bugs aside) you're saying that what you'd like is to have a single default theme that lives in chrome and then all other app-bundled themes living in extensions?
Yes. The app software update code can handle missing extensions such as DOMi and Talkback when they are located in the appdir's extensions directory so it should be fine if they are optional on install or uninstalled after install. The default theme having a directory with just an install.rdf has always been somewhat of a hack IMO. There is also some one off code that makes it so a chrome.manifest isn't required for the default theme in case the first run isn't performed by someone with write access.

I'd like to remove the requirement of the default theme id being the same for all toolkit apps as well as a few other bugs fixed.
(In reply to comment #3)

Ok, so do you want to morph this bug or INVALID?
I'm going to go with invalid. I suspect there will be additional enhancements that will be needed for this method though such as the ability to prevent uninstall for these themes, etc.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
Cool. Is there a bug on removing the install.rdf for the default theme yet?
I doubt that removing the install.rdf is going to happen anytime soon if at all. The EM requires the install.rdf to display the default theme's metadata in the mgr and removing it would mean more one-off code to handle the default theme in the EM. I've thought briefly on moving the default theme into the extensions directory but that would introduce a new set of problems that would have to be addressed.
(Assignee)

Updated

9 years ago
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.