Closed
Bug 272429
Opened 20 years ago
Closed 19 years ago
Backport FF/TB extension mechanism [Extension Manager (EM)] to Seamonkey
Categories
(SeaMonkey :: General, enhancement)
SeaMonkey
General
Tracking
(Not tracked)
RESOLVED
FIXED
seamonkey2.0a1
People
(Reporter: eyalroz1, Unassigned)
References
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
kairo
:
review+
jag+mozilla
:
superreview+
|
Details | Diff | Splinter Review |
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
Updated•20 years ago
|
Summary: backport ff/tb extension mechanism to seamonkey → Backport FF/TB extension mechanism [Extension Manager (EM)] to Seamonkey
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.)
Updated•19 years ago
|
Depends on: suiterunner
![]() |
||
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.
Attachment #219341 -
Flags: superreview?(neil)
Attachment #219341 -
Flags: review?(neil)
![]() |
||
Comment 4•19 years ago
|
||
add Mark to CC, as he's the original author of this patch
Target Milestone: --- → seamonkey1.5alpha
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?
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.
Comment 7•19 years ago
|
||
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)
![]() |
||
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.
Attachment #219364 -
Flags: review?(kairo) → review+
Updated•19 years ago
|
Attachment #219364 -
Flags: superreview?(jag) → superreview+
Comment 10•19 years ago
|
||
Fix checked in to the trunk for suiterunner builds only (WONTFIX for xpfe).
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•