Search Service:Code Design

Common Search Registry

A common datasource that contains information about all of the search engines supported by the browser. This is used by all other search UI to retrieve query and configuration information about a specific search engine.

There should be a default registry of searches held by the application and a collection configured by the user. The user should be able to remove engines in either location unless the default location is "locked" by the administrator (e.g. by restricting the user's write access to the installation directory).

It should be possible to add and remove entries to the default list when upgrading by adding and removing files.

Implementation

Each engine should be represented as a XML file. By using separate files that are easy to set down in particular distributions, it should be simple to configure the browser differently for specific distribution deals.

OpenSearch Additions

Additions to the OpenSearch format will be added using the ??? namespace. (TODO: generate a mozilla.org NS!)

Automatic Detection

After the user submits a form > N times, we can infer that the user is searching in certain situations. We can do something like this:

On Form Submission: 
  MostLikelyField = null;
  for each FormElement {
    AcLength = FormElement.autoCompleteList.length;
    if (FormElement.type == "text" && AcLength > MIN_SEARCHES &&
        !MostLikelyField || 
        AcLength > MostLikelyField.autoCompleteList.length)
      MostLikelyField = FormElement
  }
  NotifyEngineAvailable(Form, MostLikelyField, PageURL);

The NotifyEngineAvailable method shows some kind of notification that there is an engine available.

Since we slurp metadata about the engine directly from the form, we should provide content authors a way to express as an attribute on their form where an OpenSearch XML file lives, if they actually wrote one. If they supply this attribute we can ping that file every N days to check for updates.

Scriptable Addition API

The previous method of adding search engines to the search bar will continue to be supported, for Sherlock files:

window.sidebar.addSearchEngine("Sherlock Description File URL", "Icon URL", "Suggested Title", "Suggested Category");

The suggested title and suggested category parameters will be ignored.

The addition API suggested by Microsoft will likely be supported for the addition of OpenSearch plugins:

window.external.AddSearchProvider("OpenSearch Description File URL");

Location Bar DNS Failure

A preference, browser.search.dnsFailureEngine contains the ShortName of the search engine to use for searches resulting from DNS lookup failures. The Search Service implements a preference observer that changes the internal keyword.URL value every time browser.search.dnsFailureEngine changes to point to the correct resolved URL.

This feature cannot use engines that accept data only via POST methods.

Context Menu "Web Search for 'Selected Text'"

A preference, browser.search.selectionEngine contains the ShortName of the search engine to use for searches resulting from DNS lookup failures.

This feature cannot use engines that accept data only via POST methods.

Sherlock Migration

The migration phase should parse sherlock .src files from an existing installation and convert to the OpenSource format.

Mozilla's implementation of .src parsing is very, very wrong. See Ben's Search Extension for details on its rules.

Bookmark Keyword Migration

The proposed search service replaces the bookmarks keyword system for URL bar searches. It should be possible to migrate existing bookmark keywords into OpenSearch files. Need to coordinate with the Places bookmarks migration.

References

OpenSearch specifications:

1. OpenSearch Description Document 1.1 [DRAFT]
2. OpenSearch Query Syntax 1.1 [DRAFT]