FirefoxDistroAddonSpec
|
Size: 4003
Comment:
|
Size: 6047
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| * '''Launchpad Entry''': UbuntuSpec:firefox-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 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. |
|
| 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 ubuntu installer next to the "Get Extension" link; the installer shows available extension packages displayed. |
| Line 18: | Line 40: |
| == Objectives and Options == | 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. |
| Line 20: | Line 46: |
| === Educate users about ubuntu maintained extension packages === | 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. |
| Line 22: | Line 50: |
| In order to educate users about ubuntu maintained packages multiple options exist: 1. add extra tab to Add-On dialog that embeds a gnome-app-install list of available extension and allow direct installation. * Pro: useful upstream * Cons: redo much of already implemented code; only feasible for users with admin privileges. 1. extend Add-On dialog to allow user to start gnome-app-install (adapt-install) with a list of suitable exstensions * Pro: reuse gnome-app-install/adapt-install; not yet another package installation dialog * Cons: probably not for upstream; only feasible for users with admin privileges 1. provide a way to install native extensions maintained by ubuntu in the user profile * Pro: feasible for all ubuntu users (e.g. non-privileged user account) * Cons: not feasible for global extension installation on its own; distribution through .deb packages might not be most genuine way to distribute such extensions. For now, the preference seems to be the second option since it's relatively easy to do *in firefox* and most likely to get upstream approval. Option 3 is nice-to-have, but should probably go to a separate spec to be implemented once the global install option has been implemented. 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. === 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. |
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. |
| Line 59: | Line 58: |
| This spec covers plugin and extension installation on both firefox and thunderbird. | This spec proposes a simple feature-set that is possible to achieve without patching the firefox code base. |
| Line 61: | Line 61: |
| * new data for gnome-app-install (adapt-install in case of kde) with infos about ubuntu provided extensions * (probably) gnome-app-install and adapt-install need to be able use custom package data (see above) * extension manager (ffox, tbird) hooks to add blacklist/compatibility checks during extension installation * install wizard * get user confirmation to install extensions that have compatibility issues or cause crashes * allow alternative install of ubuntu packages if applicable |
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 UbuntuSpec: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. |
| Line 70: | Line 98: |
| 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 UbuntuSpec: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. |
|
| Line 71: | Line 121: |
We still need to look at the plugins part of this, plugins are done differently |
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 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
FirefoxDistroAddonSpec (last edited 2008-08-06 17:00:05 by localhost)