Status

• Extension Manager work implemented in bug 404024
• AMO API implemented in bug 399913 bug 400715 bug 400719

Has a design review been completed?

The functionality and behaviour of the feature was discussed in a meeting involving QA, UX, Firefox Developers and the AMO team.

When do you anticipate the feature landing

The feature has landed, there are some minor UI and functionality issues remaining.

Overview

Describe the goals and objectives of the feature here.

The goal of the feature is to provide an easier method of finding and installing new add-ons into the product. In particular for applications that aren't webbrowsers this is the first time that they are able to download and install add-ons without using an external tool.

Use Cases

Describe the primary use cases for the feature here.

Two main use cases:

1. User is interested in new add-ons but doesn't know what exactly. The feature presents a list of recommended add-ons available to be installed.
2. User wants something specific or has heard of a specific add-on. The feature allows them to search to find the add-on.

Requirements

List functional and non-functional requirements for the feature here, with links back to any relevant product PRD. These requirements should be prioritized.

This falls under ADD-001a (Add-ons can be installed in fewer mouse clicks), and ADD-005b (Promote the existence of Add-ons that could help the user accomplish their current task)

Schedule

Describe the rough schedule here, linking back to relevant product release milestones, as well as linking to any build/release notes.

The main feature landed shortly before Firefox 3 beta 3 with follow up minor landings following.

UI Design Documentation

use cases and expected user knowledge (terminology, metaphors, etc)

design mockups (of whatever fidelity is easiest)

UI mockups

links to relevant user data, bugs, reports, examples, etc

Design Impact

Security and Privacy

What security issues do you address in your project?

The feature retrieves and displays information retrieved from a remote source. We use https urls to retrieve the data in a secure manner. The data used comes in 4 forms, textual, image urls, links to AMO and the url of the xpi file to retrieve. For the 3 url forms the url is checked to ensure that it is one of http, https or ftp.

Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?

The feature relies on a set of preferences to enable and use the feature. Without any of the prefs the feature is just disabled and will not do anything. If the url preferences are incorrect the feature would just display an error about being unable to retrieve information.

Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.

It is assumed that the xul image element copes with invalid image data being returned from the server and does not expose any risks due to this.

Exported APIs

Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)

The retrieval of data is performed by a component with the interface nsIAddonRepository. It returns the data to a callback in the UI which implements nsIAddonSearchResultsCallback. The data is returned as a set of nsIAddonSearchResult.

Does it interoperate with a web service? How will it do so?

The feature interoperates with the AMO API service. Queries to the service are performed as part of the url which is retrieved using an XMLHttpRequest.

Explain the significant file formats, names, syntax, and semantics.

The results from the API calls are xml documents which are made up of aset of addon elements describing the search results. This xml is parsed and converted into an nsIAddonSearchResult for passing to the UI.

Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?

Yes

Does it change any existing interfaces?

No

Web Compatibility

Does the feature had any impact on Web compatibility?

No

Performance

How will the project contribute (positively or negatively) to "perceived performance"?

The feature provides a big benefit to users who install and use add-ons however it could negatively impact the project if the search results are far too slow to arrive.

What are the performance goals of the project? How were they evaluated? What is the test or reference platform and baseline results?

No specific performance goals were specified at the start of the project. The performance of the feature is being evaluated subjectively on whether it takes too long to retrieve results from the server after a user attempts a search.

Will it require large files/databases (for example, browsing history)?

The feature does not retain any data in files.

Reliability

What failure modes or decision points are presented to the user?

A failure to retrieve information from the API service is presented to the user. Also if no results are returned that is also presented.

Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

The feature does not retain any data in files.

l10n and a11y

are any strings being changed or added?

Multiple strings were added, all are available for localisation.

are all UI elements available through accessibility technologies?

There are some known accessibility issues being tracked in bug 414717

Installation, Upgrade/Downgrade/Sidegrade, and platform requirements

Does it equally support all Tier-1 platforms?

The feature is entirely implemented in javascript so will be available on any platform.

Does is have a hardware requirement (or increase minimum requirements)?

No

Does it require changes to the installer?

Nothing beyond packaging the additional component file.

Does it impact updates?

No

list the expected behavior of this feature/function when Firefox is upgraded to a newer minor release, downgraded by installation of an earlier revision, or re-installed (same version)

No expected behaviour.

configuration

Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?

There are some hidden prefs primarily aimed at different applications or distribution builds allowing them to point to a different API service for retrieving results. Users are not expected to use these preferences for anything.

Are there build options for developers? [#ifdefs, ac_add_options, etc.]

No

What ranges for the tunable are appropriate? How are they determined?

No tunables

What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

If AMO changed it's url scheme or return schema then the feature would have to be updated to match.

Relationships to other projects - are there related projects in the community?

If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?

Other Mozilla based applications can opt to activate the feature in their builds by including a set of preferences first to activate then to direct the feature to their add-ons service. They may optionally replace the nsIAddonRepository component with their own implementation to use an entirely different type of API.

Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?

No

Documentation

Do built-in Help pages need modified?

Yes the feature should be added to the product help.

Documentation for developer.mozilla.org?

This is not critical however surrounding documentation on implementing your own nsIAddonRepository could be useful.

Other

any other implementation or design related documentation

Discussion & Implications

Caveats / What We've Tried Before

links to previous design documents, discussions, etc.

Previous to this feature the extent of in-product AMO integration was the presence of some links in the Addons Manager that would open a browser window on AMO.

References

links to external documents that could inform the design of the feature