FirefoxDistroAddonSpec

Revision 5 as of 2007-05-21 13:31:12

Clear message

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

Incompatible extensions and plugins can have a negative impact on overall user-perception of firefox and even ubuntu quality.

Though the flexibile plugin/extension system in firefox is one of the big strengths of firefox, it can be cumbersome, especially when it comes to extensions providing native components.

This document specifies how the overall plugin/extension user-experience can be improved now, e.g. without changes to the actual firefox code base.

Most likely, there will be a separate specification for use-cases and features that can only be implemented by adapting the firefox upstream code base first.

Rationale

Bad performance, frequent crashes and broken features due to extensions can contribute to an overall bad user-experience.

Further, users are often not aware about the fact that ubuntu ships prepackaged and quality assured extensions/plugins.

Use Cases

A. User X wants to install extension Z. X goes to Tools->Add-On Dialog and finds a link that opens ubuntu installer next to the "Get Extension" link; the installer shows available extension packages displayed.

B. User X visits site that uses plugin Y. X has no Y support yet, so the plugin wizards opens when he clicks on the "Install Missing Plugins ..." link. In addition to the plugins provided by the default PluginFinderService hosted at mozilla, X sees ubuntu packaged plugins which he can install through apt:// protocol handler.

C. User X installs extension Z from site Y. The extension is known to crash firefox frequently. Firefox denies the install of such an extension.

D. User X installs extension Z from site Y. Like in the previous use case the extension is known to cause crashes due to incompatible native components; fortunately, there is an ubuntu packaged build available, so the user is given the option to use that package next to the warning that the extension is known to cause crashes.

Scope

This spec proposes a simple feature-set that is possible to achieve without patching the firefox code base.

Thus, we introduce a firefox extension package and install it by default.

In addition, there will be the need to setup and maintain two webservices: the pluginfinderservice and the extension blocklist service.

For the app-installer we need an data package that contains information about ubuntu packaged extensions.

Design

The Design is based upon the assumption that this feature can be realized as a firefox extension package.

ad A. ubuntu extension provides a dynamic overlay that adds a link to extension manager (Tools->Add-On). Clicking the link will open the installer application with all available extension packages displayed. The data for the installer will be provided by a data package.

ad B. a plugin finder webservice merges items for ubuntu packaged extensions with the actual results from official mozilla plugin finder service. We use a special package install uri that makes use of the 'apt' protocol handler defined in the apt-firefox-archive-handler spec.

ad C. an extension blocklist webservice that adds extensions known to cause frequent crashes on ubuntu firefox builds to the results from original upstream blocklist webservice.

ad D. is out of scope since it needs firefox codebase patching. This feature should be dealt with in a separate specification.

Implementation

ad A. Since the apt url-handler will probably not allow to open ubuntu application installer with a custom application data package, the implementation has to register an on-click listener on the "Get ubuntu Extension" link overlayed into extension manager UI. Once the on-click listener is invoked, the extension should start the ubuntu application installer with the custome firefox extension application data package as data-source. This data package will be produced from a manual maintained list of packaged extensions. This specification suggests to add two headers for extension packages in order to automatize extension package discovery at some point: {{{XB-mozilla-extension-app: target-app-id XB-mozilla-extension-ext: id-for-extension}}}

ad B. The firefox-ubuntu extension sets a custom pluginfinder service url to the pfs.datasource.url preference. The webservice implementation available through that url can use the mozilla-source-shipped PluginFinderService.php example to get things started. The idea is to merge the official results provided by mozilla.org with plugin entries that are shipped in a "known ubuntu plugin database". For ubuntu maintained plugins the manuall install url path of the plugin description will be set to apt:packagename. Once apt-firefox-archive-handler spec is implemented, users will be able to install packaged plugins from within mozilla plugin installer wizard by just one single click.

ad C. Following the spirit of use-case B. firefox-ubuntu extension will set a custom blocklist uri to the extensions.blocklist.url preference. In this way we can prevent grave extensions from being installed into ubuntu firefox. The server part of this feature needs to provide a blocklist webservice, that proxies blocklist requests to the official mozilla blocklist webservice. The result from that service should be extended by ubuntu specific knowledge before streamed back to the client. The knowledge about what extensions cause crashes should is is ment to be maintainable independently from the ubuntu release/SRU time-constraints.

ad D. out of scope as mentioned above.

Outstanding Issues

BoF agenda and discussion


CategorySpec