Closed Bug 1859389 Opened 6 months ago Closed 6 months ago

Modify desktop Suggest integration so it properly handles timestamp templates

Categories

(Firefox :: Address Bar, task, P1)

task

Tracking

()

VERIFIED FIXED
121 Branch
Tracking Status
firefox120 --- verified
firefox121 --- verified

People

(Reporter: adw, Assigned: adw)

References

Details

Attachments

(1 file)

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.

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.

Pushed by dwillcoxon@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/49bcf5f146b9
Modify desktop Suggest integration so it properly handles timestamp templates. r=daisuke

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.

Flags: qe-verify+
Flags: in-testsuite+

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
Attachment #9360738 - Flags: approval-mozilla-beta?
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → 121 Branch
QA Whiteboard: [qa-triaged]

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

Approved for 120.0b5

Attachment #9360738 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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?

Status: RESOLVED → VERIFIED
Flags: needinfo?(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!

Flags: needinfo?(adw)

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.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: