407329 - EM needs clean separation between logic and UI

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Wladimir Palant]

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.

Comment 1

[Dave Townsend [:mossop]]

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.

Comment 2

[Dave Townsend [:mossop]]

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.

Comment 3

[Wladimir Palant]

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.