Sponsored Top Sites are still displayed after the unified endpoint preference is misconfigured or left blank
Categories
(Firefox :: New Tab Page, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox130 | --- | unaffected |
| firefox131 | --- | unaffected |
| firefox132 | --- | affected |
People
(Reporter: cmuresan, Unassigned)
References
(Blocks 1 open bug)
Details
[Affected versions]:
- Firefox Nightly 132.0a1 - Build ID: 20240915215047
[Affected Platforms]:
- Windows 10
- macOS 14
- Ubuntu 22.04
[Prerequisites]:
- Have a Firefox Nightly build installed.
- Have a US or DE VPN turned on.
[Steps to reproduce]:
- Open the browser from prerequisites using a new profile.
- Open a New Tab and ensure you see Sponsored Top Sites.
- Navigate to the about:config page and accept the risks.
- Change the
browser.newtabpage.activity-stream.unifiedAds.endpointpref to blank or make a typo in the URL. - Change the
browser.newtabpage.activity-stream.unifiedAds.enabledpref to true. - Open a New Tab and wait 15-20 minutes.
[Expected result]:
- The Sponsored Top Sites are no longer displayed.
[Actual result]:
- The Sponsored Top Sites are still displayed in the page.
[Notes]:
- The Top Sites Sponsored tiles are no longer displayed if the Sponsored Shortcuts checkbox is disabled and then re-enabled.
- An error is displayed in the Browser Console that new information could not be fetched because the URL is invalid.
- The issue is still reproducible if the browser is restarted after the prefs are changed or after waiting the 15-20 mins.
- The issue is NOT reproducible if the two prefs are changed before the first Browser startup through the use of a user.js file.
- Attached a screen recording of the issue.
Comment 1•1 year ago
|
||
This does not happen with Pocket spocs, I suspect it's because it's using the old cached items from the old API.
I suspect a fix to this to use old API content isn't really a good long term solution, as we'll eventually be removing the code for the old API, and once we do we won't have that as a fallback.
We can easily detect if the endpoint is blank, or not in our approved list of endpoints, and react to that before making the request.
I don't think a typo that's not the above case is detectable. So in this case the best we can do is catch the error, and keep using any cached ads if we have them. Like we do with the stories section ads now.
Comment 2•1 year ago
|
||
Oh, I missed the part in your steps with "wait 15-20 mins"
This sounds like cache is expiring.
I think ultimately if there is a misconfigured API endpoint, the cache duration is how long we have to resolve the misconfigured endpoint before users stop seeing spocs.
I suspect there isn't much more we can or should be doing. But I'll keep looking at bit more for ideas.
Comment 3•1 year ago
|
||
If the cached data we have is from a previously valid unified ads API request, and the endpoint then becomes misconfigured, we retain a working cache for both tiles and spocs. I think this is my biggest concern.
If the previous cache is from the old API, and we misonfigure the endpoint then turn on unified ads, I think we're in a case we probably don't need to support.
Description
•