FirefoxDistroAddonSpec
|
Size: 2817
Comment:
|
← Revision 9 as of 2008-08-06 17:00:05 ⇥
Size: 6284
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| * '''Launchpad Entry''': UbuntuSpec:firefo-distro-addon-spec | * '''Launchpad Entry''': UbuntuSpec:firefox-distro-addon-support |
| Line 5: | Line 5: |
| Line 8: | Line 9: |
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. |
|
| Line 10: | Line 28: |
| Not all extensions/plugins for firefox are "good" for various definitions of good. They also can be quite hard to find. Some are also properly packaged, but this is not widely known. | 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. |
| Line 14: | Line 36: |
| * Jono wants to watch weird metal videos on youtube and needs flash support for that * Aleksander is an Ubuntu developer who wants people to use proper packages instead of downloaded extensions * On Sarahs pc, firefox is crashing all the time due to bad extensions. She doesn't know this and simply wants this to not happen. |
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. |
| Line 20: | Line 58: |
| This spec covers plugin and extension installation on both firefox and thunderbird. | 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. |
| Line 24: | Line 76: |
| === Making plugins more visible === | The design is based upon the assumption that this feature can be implemented as a firefox extension package. |
| Line 26: | Line 78: |
| These 3 options have been discussed (not necessarily in this order): | 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. |
| Line 28: | Line 84: |
| * Have an extra tab in the extension manager which embeds a g-a-i like application (or maybe even g-a-i itself) * Have an extra button next to "Get more extensions" labeled something like "Get ubuntu extensions", which launches g-a-i/adept_installer with a filter * Same as before, but launching synaptic |
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 UbuntuSpec:apt-firefox-archive-handler specification. |
| Line 32: | Line 90: |
| For now, the preference seems to be the second option since it's relatively easy to do *in firefox* and most likely to gt upstream approval. The downside of using g-a-i is that it needs to be easy to display all and only firefox extensions. A possible solution would be extra control fields like: {{{ XB-mozilla-extension-app: app-id-for-firefox-and-or-thunderbird XB-mozilla-extension-ext: id-for-extension}}} This also helps in the second part. |
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. |
| Line 38: | Line 94: |
| === Blacklisting === There are four reasons for blacklisting an extension: * It is known that the extension is broken * The extension contains native parts, which are compiled in a way that's incompatible with Ubuntu * The extension causes problems when installed together with other extensions (I'd say "conflicts" here, but Ian would probably yell "Breaks") * The extension also exists as an Ubuntu package The blacklist format should be able to express this, and also which versions of extensions are broken. The extension install process already looks at its own internal database of conflicts and does version checks. According to asac the process to plug in our own checks is fairly straightforward. |
ad D. is out of scope since it needs firefox codebase patching. This feature should be dealt with in a separate specification. |
| Line 53: | Line 99: |
| == Outstanding Issues == | 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}}} |
| Line 55: | Line 109: |
| We still need to look at the plugins part of this, plugins are done differently | 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 UbuntuSpec: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. |
| Line 57: | Line 117: |
| == BoF agenda and discussion == | 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. |
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.
FirefoxDistroAddonSpec (last edited 2008-08-06 17:00:05 by localhost)