1859389 - Modify desktop Suggest integration so it properly handles timestamp templates

Status: VERIFIED FIXED

(Firefox :: Address Bar, task, P1)

Description

[Drew Willcoxon :adw]

The suggest Rust component handles timestamp templates in URLs and exposes a couple new related suggestion properties called raw_url and raw_click_url. We'll need to modify the desktop integration for that.

Comment 1

[Drew Willcoxon :adw]

Attachment: Bug 1859389 - Modify desktop Suggest integration so it properly handles timestamp templates.

This makes sure result.payload.originalUrl is set correctly depending on Rust
vs. JS, and AMP vs. Wikipedia. The logic is getting a little messy due to all
the various combinations, but there's no way around it until we drop the JS
backend.

I tried setting raw_url (or rawUrl) on JS suggestions to match Rust
suggestions, and while that made the AdmWikipedia logic slightly nicer, it
either made the UrlbarProviderQuickSuggest._canAddSuggestion() logic a little
uglier because we need to also check raw_url for JS suggestions (snake_case),
or instead we could set rawUrl (camelCase) on JS suggestions just like Rust
suggestions, but every other property on JS suggestions uses snake_case.

This is not based on bug 1861540 because we need to uplift this, but I don't
want to uplift bug 1861540.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/49bcf5f146b9
Modify desktop Suggest integration so it properly handles timestamp templates. r=daisuke

Comment 3

[Drew Willcoxon :adw]

STR for QA

This may be hard to test because it depends on the timestamp templates in sponsored suggestions, which depend on the current date and hour. We want to check a couple things:

• Sponsored suggestions with timestamps can be dismissed successfully, e.g., they don't reappear in the next hour after you dismiss them
• When you click a sponsored suggestion and it's added to your history and then you trigger it again, the history is not shown since it duplicates the sponsored suggestion

Dismissed sponsored suggestions

1. Enable Suggest and the Rust backend: browser.urlbar.quicksuggest.rustEnabled = true
2. Trigger a sponsored suggestion, e.g. nike
3. Arrow down to the suggestion and verify it has something that looks like a timestamp in the URL. It will have the usual sponsored timestamp format: YYYYMMDDHH, e.g. 2023103004
4. Dismiss the suggestion
5. Wait until the next hour or change your computer's clock to the next hour (or day, etc.)
6. Verify the suggestion can't be triggered again

You can clear dismissed suggestions if you'd like to use the same ones for the next section by clearing browser.urlbar.quicksuggest.blockedDigests

Sponsored suggestion and history deduplification

1. Enable Suggest and the Rust backend
2. Trigger a sponsored suggestion
3. As above, please verify the suggestion URL has a timestamp in it
4. Click the suggestion
5. Wait until the next hour or change your computer's clock to the next hour (or day, etc.)
6. Trigger the suggestion again and verify a history result with the same URL (excluding the timestamp part) does not appear

The reason I say "with the same URL" is that some sponsored suggestions may redirect to a completely different URL when you click them, and Firefox won't try to de-dupe those.

Comment 4

[Drew Willcoxon :adw]

Comment on attachment 9360738 [details]
Bug 1859389 - Modify desktop Suggest integration so it properly handles timestamp templates.

Beta/Release Uplift Approval Request

• User impact if declined: This is necessary for the cross-platform Suggest experiment we plan to ship to 120.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Please see previous comment
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Small patch that only affects the Firefox Suggest feature. Covered by tests.
• String changes made/needed:
• Is Android affected?: No

Comment 5

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/49bcf5f146b9

Comment 6

[Dianna Smith [:diannaS]]

Comment on attachment 9360738 [details]
Bug 1859389 - Modify desktop Suggest integration so it properly handles timestamp templates.

Approved for 120.0b5

Comment 7

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/f738f4b434d6

Comment 8

[Cosmin Muntean [:cmuntean], Ecosystem QA]

I have verified this issue on the latest Nightly 121.0a1 build (Build ID: 20231031093058) on Windows 10 x64, macOs 13.1 and Ubuntu 20.04 x64.

• The dismissed sponsored results are not triggered even after 1h or 1 day.
• After clicking a sponsored result, no other history result with the same URL appears as described in comment 4.

I will re-verify the bug as soon as Beta 120.0b5 is available. I will remove the "qe-verify+" flag after we verify the bug in Beta build.

@Drew, I have noticed that the Amazon and Under Armour results don't contain the timestamp part in their URL. Is the timestamp hardcoded or do these results have a different mechanism?

Comment 9

[Drew Willcoxon :adw]

(In reply to Cosmin Muntean [:cmuntean], Ecosystem QA from comment #8)

@Drew, I have noticed that the Amazon and Under Armour results don't contain the timestamp part in their URL. Is the timestamp hardcoded or do these results have a different mechanism?

Some sponsored suggestions don't have timestamps at all, so that's expected. There's no obvious reason, it's just up to the partner how they generate their URLs. Thanks for checking and for verifying this bug!

Comment 10

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Thank you Drew for clarifying this.

I have verified this issue on the latest Beta 120.0b5 build (Build ID: 20231101092803) on Windows 10 x64, macOs 13.1 and Linux Mint 20.1 x64.

• The dismissed sponsored results are not triggered even after 1h or 1 day.
• After clicking a sponsored result, no other history result with the same URL appears as described in comment 4.