Closed Bug 1781766 Opened 2 years ago Closed 2 years ago

Review the uses of searchForm and either remove or replace it

Categories

(Firefox :: Search, task, P3)

task

Tracking

()

RESOLVED FIXED
112 Branch
Tracking Status
firefox112 --- fixed

People

(Reporter: standard8, Assigned: standard8)

References

Details

(Whiteboard: [snt-scrubbed][search-tech-debt])

Attachments

(2 files)

searchForm or search_form is a special field that we've had on our search engine interfaces for a while. According to the interface documentation, searchForm is:

A URL string pointing to the engine's search form.

It is not in the OpenSearch documentation nor in the WebExtension documentation.

It looks like we are inconsistently defining it: https://searchfox.org/mozilla-central/search?q=search_form&path=&case=false&regexp=false

Some places we're using just the base page of the site, some places we're using the full search url with replacements (that would never be replaced).

It is used in a couple of places in address bar code, and a couple of places in newtab code.

At a quick glance, it looks like we are only matching against the start of the URL in a lot of these cases - so we might be able to compare with an empty submission url instead (a submission url with an empty string for a query).

However, one of the newtab cases seems potentially more complex (as the search form and submission url differ), so we should check we wouldn't break that case if we make changes.

Overall, I think we should either drop support for searchForm or replace it with using an empty submission url.

In dropping support for searchForm, one should consider removing the reference to it in Bing test (and head_searchconfig).

searchForm is used in the Bing test.

One of the assertions will be a check to make sure that the partner code is the same as the one defined in the manifest.json. Worth noting, the actual check looks at whether the input is included in the URI. For example, one could put "https://www.bing.com/search?" for the value of searchFormUrlCode and the assertion would be true.

It's utility in this specific case seems limited since searchUrlCode in the test is the property that can be manipulated once the query params from search-config.json are loaded into the browser. It's worth pointing out other searchconfig tests don't state expected searchFormUrlCode, so on the surface it doesn't seem too tricky to remove it from this part of the code.

Severity: -- → N/A
Priority: -- → P3
Whiteboard: [snt-scrubbed][search-tech-debt]
Assignee: nobody → standard8
Status: NEW → ASSIGNED

Having looked around a bit, I think I this is the best definition I can come up with:

  /**
   * The searchForm URL points to the engine's organic search page. This should
   * not contain neither search term parameters nor partner codes, but may
   * contain parameters which set the engine in the correct way.
   *
   * This URL is typically the prePath and filePath of the search submission URI,
   * but may vary for different engines. For example, some engines may use a
   * different domain, e.g. https://sub.example.com for the search URI but
   * https://example.org/ for the organic search page.
   */

We currently use it for:

  • Tab-to-search - to identify if the user is typing the organic search page, rather than the direct search url
  • Submitting an empty search on the search bar
  • Newtab's search shortcuts
Pushed by mbanner@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/129b3b497d3d Remove unnecessary parameters from searchForm urls in search engines. r=search-reviewers,mcheang https://hg.mozilla.org/integration/autoland/rev/bfb75058a0d8 Clarify documentation for SearchEngine.searchForm. r=search-reviewers,mcheang
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 112 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: