Why are we not seeing the firefox/thunderbird extension mechanism in seamonkey? I talking both about the front end (GUI for installing, uninstalling, enabling, disabling and configuring extensions) plus the backend (perhaps store extensions like ff/tb? Perhaps not? Even in the latter case there already exists an extension uninstaller for seamonkey which seems to work, here: http://jgillick.nettripper.com/extuninstaller ). And it seems about time to retire the install.js in favor of the ff/tb-like install.rdf

After enhanced extension manager implementation, minor design change has been made. See "Enhanced Extension Installation" ( http://www.mozilla.org/projects/firefox/extensions/em-changes.html ) and Bug 297312 for minor changes (exentensions-startup is renamed to extensions.cache.)

*** Bug 315073 has been marked as a duplicate of this bug. ***

Once SeaMonkey is running as a MOZ_XUL_APP, it's easy to get the extension manager working. This patch, originally by Mark Banner ("Standard8"), adds EM and Theme Manager to the Tasks menu in the case when we are building as such a "new toolkit" application.

add Mark to CC, as he's the original author of this patch

Uh, this patch only adds the GUI... which should probably wait until the backend is ready. Or am I misunderstanding?

(In reply to comment #4) > add Mark to CC, as he's the original author of this patch > Thanks. (In reply to comment #5) > Uh, this patch only adds the GUI... which should probably wait until the > backend is ready. Or am I misunderstanding? > The backend is ready for "suiterunner" builds - they are ones where MOZ_XUL_APP=1 is defined which is what the ifdefs in this patch check for. Whilst we're not ready to flip the switch yet for trunk builds, we're in a good enough state for suiterunner builds to add this - they already have the new chrome registry/startup/profiles in place.

Doh! I just realized I added emOverlay.xul in the wrong place :-(

Comment on attachment 219364 [details] [diff] [review] Better patch basically looks good to me, but could you please add the new file as suite/common/emOverlay.xul instead and reference it from suite/common/jar.mn (including the overlay line), so that we don't create a new file in xpfe/ just before moving all the suite-specific files out there? Actually, we might look into removing that additonal overlay at some later stage and merge it back into tasksOverlay, as we probably have too many overlays already. But that's something we can take care of once we've completely switched to suiterunner.

Fix checked in to the trunk for suiterunner builds only (WONTFIX for xpfe).