1968218 - Persisted search term is displayed after after a websearch refinement while using DDG as default engine

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[Cristian Baica [:cbaica], Release Desktop QA]

Attachment: persist bug for ddg

Found in

• Fx140.0a1

Affected versions

• Fx140.0a1
• Fx139.0

Affected platforms

• Windows
• Ubuntu
• macOS

Steps to reproduce

1. Launch Firefox and set DDG as default search engine.
2. Perform a search from the address bar.
3. Using the websearch, refine the search (input additional characters and do the search).

Expected result

• Full URL is displayed in the address bar.

Actual result

• The refined Search Term is displayed in the address bar.

Regression range

• This is not a recent regression. DDG treated sub-pages (videos, images) differently as well.

Additional notes

• This issue DOES NOT occur for Google or Bing, where the FULL URL is displayed on step 3.

Comment 1

[Chris Bellini (:cbellini)]

Results in an inconsistency with other built-in search engines, but could benefit with follow-up experience review as part of Scotch Bonnet follow-ons.

Comment 2

[Daisuke Akatsuka (:daisuke)]

Hi James!
It seems that this issue happens since we have only two search engines (duckduckgo and qwant) in Remote Settings.
Can we add more engines to them, or do we have any constraints?

Comment 3

[Daisuke Akatsuka (:daisuke)]

Or, should we cover by SearchEngine.searchTermFromResult(uri)?

Comment 4

[James Teow [:jteow]]

Hmm so the reason why this is sort of different from Bing and Google is searches using an in content search boxes result in an entirely different URL.

I suppose we could try making the behaviour consistent and just do either one of the following:

• Have all searches in the search box result in the search terms persisting - Change Google/Bing/etc. to persist
• Never have it do it - Unfortunately, this would require additional logic or state keeping because persisted search relies heavily on looking at the URL to extract the current state and doesn't really "know" where the search originally came from (e.g. from a SAP? From content?).

I feel like a lot of the complexity with Persisted Search could be solved by knowing and storing whether or not the search actually came from a SAP or if it came from content.

The engines in Remote Settings were really meant for just search engines with single page app like behaviour where we explicitly spell out the key value pairing that match a search page. For example, in DDG's case it's ia=web.

Comment 5

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1968218: Handles empty arrays or undefined includeParams

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0d2014ac189f
https://hg.mozilla.org/integration/autoland/rev/91d01888d36c
Handles empty arrays or undefined includeParams r=jteow

Comment 7

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/91d01888d36c

Comment 8

[Adrian Florinescu [:aflorinescu]]

James, can you please clarify what the expected result is here? On websearch refine we still reproduce the persisted ddg search term instead of full link.

Comment 9

[James Teow [:jteow]]

Hi Adrian, we closed this bug because we updated the code base to allow us to fix this issue, but we still need to update Remote Settings in Bug 2007314 at which point the behaviour should be fixed. Is it alright if we use that bug to QA instead?