1832555 - Multiple history entries are registered after a Top Pick result is clicked

Status: NEW

(Firefox :: Address Bar, defect, P3)

Description

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Attachment: multiple history registered.mp4

[Notes]

• I have observed that the first history is created for "domain.com" and then for the redirect one with "www.domain.com". If there is an extra redirect like "www.domain.com/en-US" another history is registered.
• Also the first history register doesn't have a favicon even if the Top Pick has.

[Affected versions]:

• Nightly 115.0a1 (Build ID: 20230509215006)
• Beta 114.0b2 (Build ID: 20230509180058)
• Release 113.0 (Build ID: 20230504192738)

[Affected Platforms]:

• Mac 12.4
• Windows 10 x64
• Linux Mint 20

[Prerequisites]:

• Have a new profile with the following prefs set:
• browser.search.region to US
• browser.urlbar.quicksuggest.dataCollection.enabled to true
• browser.urlbar.merino.providers to adm,top_picks
• browser.urlbar.bestMatch.enabled to true

[Steps to reproduce]:

1. Open the Nightly browser with the profile from the prerequisites.
2. Type "minecraft" in the awesome bar.
3. Click on the minecraft Top Pick result.
4. Close the tab and open a new one.
5. Type again "minecraft" in the awesomebar.
6. Oserve the Firefox Suggest results.

[Expected result]:

• Only one minecraft history website is displayed in the Firefox Suggest section.

[Actual result]:

• Multiple histories for the minecraft website are displayed in the Firefox Suggest section.

[Aditional Notes]:

• Attached is a screen recording of the issue.

Comment 1

[Abhishek]

Hey :cmuntean, we are working to resolve this issue and should be able to land the fix very soon.

Comment 2

[Abhishek]

Submitted a PR for review to resolve this.

Comment 3

[Drew Willcoxon :adw]

Assigning this to Abhishek and giving it a low priority because this is a relatively minor issue. It shouldn't really even happen for users with a fair amount of history because redirects are given a very low frecency, so if the user has other history that matches their search string, it will likely be shown instead of these low-frecency redirects.

Comment 4

[Abhishek]

In light of the comment 1 and comment 2, should we mark this issue as won't fix?

Comment 5

[janet [:janet]]

@abhishek - it looks like your PR to resolve this was merged last week. Is the issue resolved? I don't think it makes sense to wontfix this without product input on what we want the new user (no history) experience to be.

Comment 6

[Abhishek]

@janet This issue is not resolved. The PR was created with the intention to fix this issue but resolving this issue raised some valid concerns (details in comment) because of which we didn't go ahead with fixing it. Btw, the PR does reduce the number of history entries that users will now see.

You are right. We can get the product people involve in reaching a conclusion about this issue. Adding needinfo for Nive.

Comment 7

[Drew Willcoxon :adw]

The experiment has shipped so this is moot as far as that goes, but it will still be an open issue if/when the feature ships to more users.

Comment 8

[Drew Willcoxon :adw]

Is it all right if I unassign you, Abhishek? I don't believe you're working on this anymore -- very sorry if I'm wrong! I'd like the bug to reflect the current status.

This is still a valid bug and we need some Product direction but it's unlikely we'll work on this.

Comment 9

[Abhishek]

Hey Drew. You are right. I am not working on this. Thanks a lot for unassigning me from this bug.