1879278 - Could not load engine [e-mail]: Error: Search terms missing from engine URL

Status: RESOLVED FIXED

(Firefox :: Search, defect, P3)

Description

[Ardelean Oana, Desktop QA [:oardelean]]

Attachment: gpspnepl.Default User.zip

Notes

• Please note that this particular scenario has been reproduced using only the attached profile, and we haven’t had any success yet in trying to reproduce again on a fresh profile.

Found in

• Firefox Nightly 124.0a1;

Affected versions

• Firefox Nightly 124.0a1;

Tested platforms

• Windows 10;
• Ubuntu 22;

Affected platforms

• Windows 10;
• Ubuntu 22;

Unaffected platforms

• N/A;

Preconditions

• Use the attached profile.

Steps to reproduce

1. Launch Firefox using the attached profile.
2. Go to about:preferences#search and observe the search engines in the Search Shortcuts list.

Expected result

• Bing is present in the Search Shortcut list.

Actual result

• Bing is missing from the Search Shortcut list.

Regression range

• Not a regression.

Additional notes

• console logs:

SearchService: addEnginesFromExtension: [e-mail] SearchService.sys.mjs:638:21
SearchEngineSelector: fetchEngineConfiguration: google,ddg,wikipedia,ebay,amazondotcom-us,bing SearchEngineSelector.sys.mjs:298:23
SearchService: _makeEngineFromConfig:
Object { name: "Bing", urls: {…}, aliases: (1) […], partnerCode: "MOZI", classification: "general", identifier: "bing", webExtension: {…} }
SearchService.sys.mjs:3551:21
Could not load engine [e-mail]: Error: Search terms missing from engine URL.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:oardelean, if you think that's a regression, could you try to find a regression range using for example mozregression?

Comment 2

[Mark Banner (:standard8)]

I think this was sort-of triggered by bug 1872409 but not strictly a regression from that. We published a remote settings update to search-config-v2 - that hasn't made it into the trees yet, so fresh profiles using the new configuration will be fine. However, if they receive updates to remote settings, then they will stop working.

In that bug, we just added a trending URL for Bing. We already have one for Google, but that has (maybe incorrectly) a searchTermParamName defined in the configuration.

Unfortunately the code currently requires that all url types should have a searchTermParamName. We should probably avoid that check when the type of url is trending.

We should probably also add a test for this. I think we should potentially have a toolkit/components/search test specifically for the new config setup, where the config includes all of the main options for an engine (name, all types of urls with all the param type variations, partner codes, categories etc), and verifies that an engine gets created for it. We have some of this for WebExtensions, but I think we should be testing the config through to AppProvidedSearchEngine process.

We might want to split the test off to a separate bug though - get the url part fixed so that QA can continue, and then land the test separately as part of the ongoing config work.

Comment 3

[Mandy Cheang [:mcheang][she/her]]

Attachment: Bug 1879278 - Do not check for search terms in trending URLs. r=Standard8!

Trending URLs do not have search terms because they are suggestions without a
search. When constructing the Url in AppProvidedSearchEngine, we should not
error out when a trending url does not have search terms, this is to be
expected.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3181377ca265
Do not check for search terms in trending URLs. r=Standard8 DONTBUILD

Comment 5

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/3181377ca265