1892462 - The existing wallpaper from the New Tab page is removed if the "Not now" button from the Wallpaper Onboarding spotlight is clicked

Status: NEW

(Firefox :: New Tab Page, defect, P1)

Description

[Marius Coman [:mcoman], Ecosystem QA]

Attachment: rec of the issue.gif

[Affected versions]:

• Firefox Beta 126.0b2 - Build ID: 20240417091940
• Firefox Nightly 127.0a1 - Build ID: 20240418214121

[Affected Platforms]:

• Windows 11 x64
• macOS 14.1
• Ubuntu 22.04 x64

[Prerequisites]:

• Have the following prefs in the "about:config" page:
  • browser.newtabpage.activity-stream.asrouter.devtoolsEnabled set to true
  • browser.newtabpage.activity-stream.newtabWallpapers.enabled set to true
• Have any wallpaper set to the new tab page.

[Steps to reproduce]:

1. Open the browser using the profile from the prerequisites.
2. Navigate to "about:asrouter" and paste sample JSON into a text field.
3. Click the "Modify" button displayed near the text field from step 2.
4. Click the "Not now" button from the bottom part of the spotlight.
5. Open a new tab page and observe the background.

[Expected result]:

• Nothing happens. The existing wallpaper is still applied.

[Actual result]:

• No wallpaper is applied anymore.

[Additional Notes]:

• This issue is not reproducible if the spotlight is dismissed using the "Esc" key or the "X" button.
• Attached a screen recording of the issue.

Comment 1

[Punam Dahiya [:pdahiya]]

Same as https://bugzilla.mozilla.org/show_bug.cgi?id=1892461#c1 we should consider targeting experiment to users who don't have wallpaper pre-installed

Comment 2

[Punam Dahiya [:pdahiya]]

Changing component for triage help from NewTab team thanks

Comment 3

[Mike Conley (:mconley) (:⚙️)]

I ran the nascent Triage Bot tool against this, and this was the result:

Summary

Bug 1892462 — the New Tab wallpaper is wiped when the user clicks "Not now" on the Wallpaper Onboarding Spotlight (but not when dismissing via Esc/X).

What I found. The Spotlight wallpaper picker changes the wallpaper purely through a generic SET_PREF action on browser.newtabpage.activity-stream.newtabWallpapers.wallpaper. In contrast, the theme picker in the same multistage framework has a real preview/revert path (AWGetSelectedTheme/AWSelectTheme + initialTheme + applyThemeIfNeeded + persistActiveTheme, wired through spotlight.js and AboutWelcomeChild.sys.mjs). Wallpaper has no such revert — so any button carrying a wallpaper SET_PREF commits it immediately and permanently, while a pure dismiss (Esc/X, no action) leaves it alone. That precisely explains the reported asymmetry.

Remediation is either message-level (decline button shouldn't set the wallpaper pref; target users without a wallpaper — matching pdahiya's comment), or a tree-code hardening that mirrors the theme preview/revert for wallpaper.

Confidence is medium: I localized the mechanism firmly in code, but the primary/simplest fix is at the experiment-message level (outside the tree), and the specific 2024 test message is no longer live.