Closed
Bug 407329
Opened 17 years ago
Closed 14 years ago
EM needs clean separation between logic and UI
Categories
(Toolkit :: Add-ons Manager, defect)
Toolkit
Add-ons Manager
Tracking
()
VERIFIED
FIXED
mozilla1.9.3a5
People
(Reporter: ecfbugzilla, Assigned: mossop)
References
Details
(Whiteboard: [AddonsRewrite])
Current implementation of the extension manager component is suboptimal to say the least. Instead of using callbacks this component displays its own messages and dialogs on several occasions meaning that it is tailored to Firefox. Any application with a different UI concept has big trouble using the extension manager, getting rid of foreign UI without disabling the extension manager entirely is pretty much impossible. The sore spots in detail: 1. nsIExtensionManager.addDownloads method doesn't offer an obvious way to track the installation of the items added. By passing your own XPInstallManager you can get notifications for XPInstall (download) progress. However, e.g. on compatibility errors the extension manager will simply show an error message, abort the installation and still give the caller SUCCESS. Even if the installation was successful, the caller doesn't know whether a restart is required and what the ID of the installed item is. While the first piece of information can be retrieved from the extensions datasource (non-obvious), the only way to get the second seems to be watching additions to that datasource. Proposal: void addDownloads([array, size_is(itemCount)] in nsIUpdateItem items, in unsigned long itemCount, in nsIAddonUpdateListener listener); The listener should report installation errors in the INSTALL_DONE call. It also should set the extension ID correctly in the addon parameter passed in this call rather than keeping whatever the addDownloads caller put there (usually the download URL, the caller doesn't know better). Make sure that the use of SUCCESS/REBOOT_NEEDED return codes reflects the opinion of the extension manager rather than using whatever XPInstall's obsolete code thinks. 2. Compatibility check on app startup - the extension manager shouldn't just run its UI when you start up after an update. At the very least, it should be configurable what dialog is shown. Ideally, the startup logic should be extracted in a separate component that can be replaced. I think that's the two biggest problems but there is a bunch of other places where the extension manager expects a particular UI - and those also needs to be fixed.
Updated•17 years ago
|
Summary: Need clean separation between logic and UI → EM needs clean separation between logic and UI
Updated•16 years ago
|
Flags: wanted-firefox3.1?
Assignee | ||
Comment 1•16 years ago
|
||
Due to the amount of API change that would be necessary this is not really going to be possible to do for 3.1. However it is something that we could do for 4.0.
Updated•16 years ago
|
Product: Firefox → Toolkit
Updated•16 years ago
|
Flags: wanted1.9.1? → wanted1.9.2?
Assignee | ||
Updated•15 years ago
|
Target Milestone: --- → mozilla1.9.2
Assignee | ||
Updated•15 years ago
|
Target Milestone: mozilla1.9.2 → mozilla1.9.3
Updated•15 years ago
|
Flags: wanted1.9.2?
Assignee | ||
Comment 2•14 years ago
|
||
Hey, I was bang on the money, though we probably renamed versions a bunch since then. The new EM doesn't open any UI anymore, except for the install confirmation dialog but that can be overridden with a custom component.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 3•14 years ago
|
||
Yes, great job on the new add-ons manager, the new API is magnitudes better. If I had to create my own UI for add-on managing these days it would be a lot simpler than back when I filed this bug. Marking as verified, all my problems with the old API have been resolved.
Status: RESOLVED → VERIFIED
Updated•14 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•