Closed Bug 272429 Opened 15 years ago Closed 14 years ago

Backport FF/TB extension mechanism [Extension Manager (EM)] to Seamonkey

Categories

(SeaMonkey :: General, enhancement)

enhancement
Not set

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.0a1

People

(Reporter: eyalroz, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

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
Keywords: qawanted
Depends on: 255807
Summary: backport ff/tb extension mechanism to seamonkey → Backport FF/TB extension mechanism [Extension Manager (EM)] to Seamonkey
Keywords: qawanted
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. ***
Depends on: suiterunner
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.
Attachment #219341 - Flags: superreview?(neil)
Attachment #219341 - Flags: review?(neil)
add Mark to CC, as he's the original author of this patch
Target Milestone: --- → seamonkey1.5alpha
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.
Attached patch Better patchSplinter Review
Attachment #219341 - Attachment is obsolete: true
Attachment #219364 - Flags: superreview?(jag)
Attachment #219364 - Flags: review?(kairo)
Attachment #219341 - Flags: superreview?(neil)
Attachment #219341 - Flags: review?(neil)
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.
Attachment #219364 - Flags: review?(kairo) → review+
Attachment #219364 - Flags: superreview?(jag) → superreview+
Fix checked in to the trunk for suiterunner builds only (WONTFIX for xpfe).
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Duplicate of this bug: 326292
You need to log in before you can comment on or make changes to this bug.