1933722 - [Experiment] The “Show less frequently” cap cannot be reached after the feature is enabled and the browser is NOT restarted

Status: NEW

(Firefox :: Address Bar, defect, P3)

Description

[Alexandra Berar [:aberar], Ecosystem QA]

[Notes:]

• The issue is also reproducible with the Weather results.
• The issue is NOT reproducible if the browser is restarted after the feature is enabled.

[Affected versions]:

• Firefox Beta 134.0b1 - Build ID: 20241125200000 (changed channel in Release)
• Firefox Nightly 135.0a1 - Build ID: 20241127095617

[Affected Platforms]:

• Windows 11 x64
• macOS Sequoia 15.0.1
• Ubuntu 22.04 x64

[Prerequisites]:
Have following prefs set:

• browser.search.region = US
• browser.urlbar.yelp.mlEnabled = true
• browser.urlbar.quicksuggest.mlEnabled = true
• browser.ml.enable = true

[Steps to reproduce]:

1. Open the browser using the profile from the prerequisites.
2. Open a new tab and trigger an ML Yelp result (eg: build).
3. Click the Feedback menu button and click the "Show less frequently" option.
4. Dismiss and focus on the address bar.
5. Type one more character to the typed keyword (e.g. "build + space").
6. Click the Feedback menu button and click the "Show less frequently" option.
7. Dismiss and focus on the address bar.
8. Type one more character to the typed keyword (e.g. "buildi").
9. Click the Feedback menu button and click the "Show less frequently" option.
10. Dismiss and focus on the address bar.
11. Type one more character to the typed keyword (e.g. "buildin").
12. Click on the “Feedback” button and observe the options.

[Expected result]:

• The “Show less frequently” option doesn’t appear if the cap has been reached.

[Actual result]:

• The “Show less frequently” option appears even if the cap has been reached.

[Additional Notes]:

• A video of this issue is attached here.

Comment 1

[Drew Willcoxon :adw]

Thanks. The key point is what Cosmin said in bug 1930697 comment 10:

It seems that the “show less frequently” cap is not reached if the option is used right after the feature is enabled and the browser is not restarted. Is reproducible only on the first session where the feature was enabled.

In addition, it must be the case that either (a) no suggestions were ever enabled in a previous app session or (b) Suggest became enabled in the same app session before any suggestion types became enabled.

So these STR do not reproduce the bug:

1. Enable Suggest and at least one suggestion type, e.g., sponsored
2. Restart Firefox
3. Install the NER Yelp experiment or enable the feature in about:config

These STR also do not reproduce it:

1. Start a new profile in the U.S. (so that Suggest is enabled by default)
2. Install the NER Yelp experiment or enable the feature in about:config

We aren't planning to run experiments outside the usual Suggest population, so there should not be any actual users who hit this. Every user who receives a Suggest experiment will have had Suggest and some suggestion type enabled. One of the two STR I just listed will apply to every user in the experiment.

Even if we were planning on running experiments outside the Suggest population, we could set the yelpShowLessFrequentlyCap Nimbus variable to avoid this bug. I went ahead and added it to the NER Yelp experiment just to be safe. There are similar variables for other suggestion types too.

In summary, this is a valid bug that we should fix, but it's not urgent, so I'll decrease its severity.

If I'm wrong about any of that and you're able to reproduce the problem in a way that's not consistent with what I've said, please let me know.

---

Technical details:

SuggestStore::fetch_global_config() doesn't ingest from remote settings. It only returns the config currently stored in the DB. If there is no config in the DB, then it returns a default config with show_less_frequently_cap set to zero.

SuggestBackendRust fetches the config when it ingests all enabled suggestions. If no suggestions are enabled at that time, the backend still fetches the config but nothing is actually ingested from RS.

The backend ingests all enabled suggestions only in a few cases: when Suggest becomes enabled, on app startup if Suggest is enabled, and when the 24-hour ingest timer fires. If Suggest is enabled and then later an individual suggestion type is enabled, only that type is ingested, not all types and not the global config.

All of that means if you enable Suggest without first enabling any suggestion type, and then you enable weather or Yelp (or any other type) in the same app session, you'll hit this bug.