Eyal Rozenberg Reporter
	Description • 20 years ago

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

	WADA:World Anti-bad-Duping Agency
	Comment 1 • 19 years ago

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.)

	Stephen Donner [:stephend] Not actively reading bugmail
	Comment 2 • 19 years ago

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

	Robert Kaiser
	Comment 3 • 19 years ago

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.

	Robert Kaiser
	Comment 4 • 19 years ago

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

	Eyal Rozenberg Reporter
	Comment 5 • 19 years ago

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

	Mark Banner (:standard8)
	Comment 6 • 19 years ago

(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.

	neil@parkwaycc.co.uk
	Comment 8 • 19 years ago

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

	Robert Kaiser
	Comment 9 • 19 years ago

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.

	neil@parkwaycc.co.uk
	Comment 10 • 19 years ago

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