Ubuntu Wiki

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.

• Launchpad Entry: firefox-distro-addon-support

• Packages affected: firefox, thunderbird, packaged extensions & plugins

Summary

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

Though the flexible 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 the Ubuntu installer next to the "Get Extension" link; the installer displays available extension packages.

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. As 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 specification 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 set up 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.

Suggesting alternatives in case extensions/plugins being installed are known to be broken is out of scope of this specification and should be dealt with in a separate specification, as adding such a feature will require some firefox codebase modifications.

Design

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

ad A. an 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 web service 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 specification.

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

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 URI handler will probably not allow opening the Ubuntu application installer with a custom application data package, the implementation has to register an on-click listener on the "Get Ubuntu Extension" link overlaid onto the extension manager UI. Once the on-click listener is invoked, the extension should start the Ubuntu application installer with the custom firefox extension application data package as a 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 automate 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 web service 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 manual install URL path of the plugin description will be set to apt:packagename. Once the apt-firefox-archive-handler specification is implemented, users will be able to install packaged plugins from within the mozilla plugin installer wizard with a single click.

ad C. Following the spirit of use-case B., the firefox-ubuntu extension will set a custom blocklist URL 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 web service, that proxies blocklist requests to the official mozilla blocklist web service. 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 is intended to be maintainable independently of the Ubuntu release/SRU time-constraints.

ad D. out of scope as mentioned above.

CategorySpec