2066344 - Add telemetry for theme selection in the New Tab customization panel

Status: VERIFIED FIXED

(Firefox :: New Tab Page, task)

Description

[Gabriel H [:gharp, :gabriel]]

Placeholder, 2026-08-25. Theme picker telemetry is being built centrally in bug 2052547 (RECOMP-1750), currently in review. New Tab already sets installsource and layout at both render sites, so theme selections should attribute correctly with no New Tab code change. Remaining gaps are the unimplemented theme_picker.shown event (no denominator for picker interaction), unrecorded appearance and native theme changes, and no newtab_visit_id for visit-level joins. Scope pending guidance from :tgiles.

Comment 1

[Gabriel H [:gharp, :gabriel]]

Assigned to Nina. Will clarify acceptance criteria after a call tomorrow

Comment 2

[Gabriel H [:gharp, :gabriel]]

Nina -- see updated AC in JIRA ticket. We are still dependent on 2052547 for some aspects but can proceed with others.

Comment 3

[Gabriel H [:gharp, :gabriel]]

Update based on https://bugzilla.mozilla.org/show_bug.cgi?id=2052547: newtab needs to manually call the shown() event whenever it's rendered.

Comment 4

[Mark Striemer [:mstriemer]]

Note that the shown() method should be called when the picker is actually shown, not just rendered. It can be (and likely should be) called each time it becomes shown. So when the Customize button opens the panel <theme-picker layout="compact"> fires a shown event and when See more themes is clicked to show the deeper panel the <theme-picker layout="full"> should call its shown()

Comment 5

[Nina Pypchenko [:nina-py]]

Attachment: Bug 2066344 - Part 1: Call the theme picker's shown() when a New Tab picker becomes visible

New Tab now calls the toolkit theme picker's shown() whenever one of
its pickers comes into view, so the theme_picker.shown event is
recorded for about:newtab: for the compact picker when the Customize
panel opens, and for the full picker when the "See more themes" subpanel
opens. The picker element loads lazily, so the call waits for the element
to be defined and is skipped if the panel has moved on by then, or if the
Firefox build is too old to have shown().

Note that toolkit's ThemePickerChild actor records shown at most once
per document, whichever layout reports first. The Customize panel always
opens on its root panel, so the compact picker reports first and the full
picker's event from about:newtab is currently dropped. New Tab still
calls shown() every time either picker appears, so if toolkit later
records one event per layout, the full picker's events will start
arriving without any change on the New Tab side.

Comment 6

[Nina Pypchenko [:nina-py]]

Attachment: Bug 2066344 - Part 2: Track which New Tab customize subpanel is open with a single activeSubpanel value

Refactor how the customize panel tracks which subpanel is open. Part 3 of
this stack adds telemetry for the customize panel, and that telemetry
needs one value that names the open subpanel. The Base component now
holds that value as activeSubpanel, so at most one subpanel is open at
a time, and the CustomizeMenu component derives each subpanel's open
state and its own styling from activeSubpanel. This removes the four
booleans and the callback each subpanel used to report its state back
up. The subpanel props are unchanged.

This also fixes the panel styling itself as if no subpanel were open
after one subpanel replaced another, which Dre noted on D324515.

The Jest tests for the Base component now cover the new state: opening,
toggling and closing subpanels, one subpanel at a time, and the panel
taking its styling from the open subpanel. These replace the Enzyme
tests deleted in this patch.

Comment 7

[Nina Pypchenko [:nina-py]]

Attachment: Bug 2066344 - Part 3: Add telemetry for opening the New Tab customize panel and its subpanels

Record in the newtab ping when the Customize panel opens, when one of
its subpanels opens and which one, and when "Explore more themes" is
clicked in the themes subpanel. The CustomizeMenu component records the
two open events at the point where the panel becomes visible, so every
way of opening it counts the same way, whether from the customize
button, a message, or the widgets context menu. The "Explore more
themes" button reports its click as a user event, the way the other
New Tab clicks reach the TelemetryFeed module.

The panel open reuses the SHOW_PERSONALIZE user event name, so the
seven entry points that already sent that event are changed to stop
sending it. Nothing was listening for the event before this patch, and
now that the TelemetryFeed module is aware of it, leaving those
dispatches in place would count every open twice.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/72b0ccafc2a5
https://hg.mozilla.org/integration/autoland/rev/80f09f443412
Part 1: Call the theme picker's shown() when a New Tab picker becomes visible r=maxx
https://github.com/mozilla-firefox/firefox/commit/7d16c6c13427
https://hg.mozilla.org/integration/autoland/rev/b6bf1e5497aa
Part 2: Track which New Tab customize subpanel is open with a single activeSubpanel value r=maxx
https://github.com/mozilla-firefox/firefox/commit/5bc47f3a9e4a
https://hg.mozilla.org/integration/autoland/rev/a17bac684f80
Part 3: Add telemetry for opening the New Tab customize panel and its subpanels r=maxx

Comment 9

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/80f09f443412
https://hg.mozilla.org/mozilla-central/rev/b6bf1e5497aa
https://hg.mozilla.org/mozilla-central/rev/a17bac684f80

Comment 10

[Nina Pypchenko [:nina-py]]

Attachment: Bug 2066344 - Part 1: Call the theme picker's shown() when a New Tab picker becomes visible

New Tab now calls the toolkit theme picker's shown() whenever one of
its pickers comes into view, so the theme_picker.shown event is
recorded for about:newtab: for the compact picker when the Customize
panel opens, and for the full picker when the "See more themes" subpanel
opens. The picker element loads lazily, so the call waits for the element
to be defined and is skipped if the panel has moved on by then, or if the
Firefox build is too old to have shown().

Note that toolkit's ThemePickerChild actor records shown at most once
per document, whichever layout reports first. The Customize panel always
opens on its root panel, so the compact picker reports first and the full
picker's event from about:newtab is currently dropped. New Tab still
calls shown() every time either picker appears, so if toolkit later
records one event per layout, the full picker's events will start
arriving without any change on the New Tab side.

Original Revision: https://phabricator.services.mozilla.com/D324867

Comment 11

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: None visible to users; this is telemetry only. Without it, Firefox 157 ships the theme picker in the New Tab customize panel with no measurement of it: no theme_picker.shown events from about:newtab, and no events for opening the customize panel, its subpanels or "Explore more themes". The team would have no data on whether people find and use the picker during its first release cycle, and the earliest data would come from 158.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing: 1. Open a new tab, open the Browser Toolbox, run Services.fog.testResetFOG().

2. Open the Customize panel; Glean.newtab.customizePanelOpen.testGetValue() returns one event.
3. Click on "See more themes"; Glean.newtab.customizePanelSubpanelOpen.testGetValue() returns one event with panel set to themes_management. Run await Services.fog.testFlushAllChildren() and then Glean.themePicker.shown.testGetValue(): one event with source set to about:newtab.
4. Click "Explore more themes" (with about:addons already open in another tab so the new tab is not replaced); Glean.newtab.appearanceExploreMoreThemesClick.testGetValue() returns one event.

• Risk associated with taking this patch: low
• Explanation of risk level: All code is under browser/extensions/newtab plus three new Glean event definitions. Parts 1 and 3 only add telemetry calls; the theme picker call is skipped on any build without shown(), so nothing breaks if the toolkit side is missing. Part 2 is a small state refactor in the customize panel with no visible change in normal use. Full New Tab test suites pass on the rebased stack.
• String changes made/needed?: None
• Is Android affected?: no

Comment 12

[Nina Pypchenko [:nina-py]]

Attachment: Bug 2066344 - Part 1: Call the theme picker's shown() when a New Tab picker becomes visible

New Tab now calls the toolkit theme picker's shown() whenever one of
its pickers comes into view, so the theme_picker.shown event is
recorded for about:newtab: for the compact picker when the Customize
panel opens, and for the full picker when the "See more themes" subpanel
opens. The picker element loads lazily, so the call waits for the element
to be defined and is skipped if the panel has moved on by then, or if the
Firefox build is too old to have shown().

Note that toolkit's ThemePickerChild actor records shown at most once
per document, whichever layout reports first. The Customize panel always
opens on its root panel, so the compact picker reports first and the full
picker's event from about:newtab is currently dropped. New Tab still
calls shown() every time either picker appears, so if toolkit later
records one event per layout, the full picker's events will start
arriving without any change on the New Tab side.

Original Revision: https://phabricator.services.mozilla.com/D324867

Comment 13

[Nina Pypchenko [:nina-py]]

Attachment: Bug 2066344 - Part 2: Track which New Tab customize subpanel is open with a single activeSubpanel value

Refactor how the customize panel tracks which subpanel is open. Part 3 of
this stack adds telemetry for the customize panel, and that telemetry
needs one value that names the open subpanel. The Base component now
holds that value as activeSubpanel, so at most one subpanel is open at
a time, and the CustomizeMenu component derives each subpanel's open
state and its own styling from activeSubpanel. This removes the four
booleans and the callback each subpanel used to report its state back
up. The subpanel props are unchanged.

This also fixes the panel styling itself as if no subpanel were open
after one subpanel replaced another, which Dre noted on D324515.

The Jest tests for the Base component now cover the new state: opening,
toggling and closing subpanels, one subpanel at a time, and the panel
taking its styling from the open subpanel. These replace the Enzyme
tests deleted in this patch.

Original Revision: https://phabricator.services.mozilla.com/D324868

Comment 14

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: New Tab on 157 records no theme_picker.shown impressions and no customize panel telemetry. The theme picker ships in the New Tab customize panel in 157, so the team would have no data on whether people find and use it during its first release cycle, and the earliest data would come from 158. Nothing is visible to users either way; this is telemetry only.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing: 1. Open a new tab, open the Browser Toolbox, run Services.fog.testResetFOG().

2. Open the Customize panel; Glean.newtab.customizePanelOpen.testGetValue() returns one event.
3. Open "See more themes"; Glean.newtab.customizePanelSubpanelOpen.testGetValue() returns one event with panel set to themes_management. Run await Services.fog.testFlushAllChildren() and then Glean.themePicker.shown.testGetValue(): one event with source set to about:newtab.
4. Click "Explore more themes" (with about:addons already open in another tab so the new tab is not replaced); Glean.newtab.appearanceExploreMoreThemesClick.testGetValue() returns one event.

• Risk associated with taking this patch: low
• Explanation of risk level: All code is under browser/extensions/newtab plus three new Glean event definitions. Parts 1 and 3 only add telemetry calls; the theme picker call is skipped on any build without shown(), so nothing breaks if the toolkit side were missing. Part 2 is a small state refactor in the customize panel with no visible change in normal use. Full New Tab test suites pass on the rebased stack.
• String changes made/needed?: None
• Is Android affected?: no

Comment 15

[Nina Pypchenko [:nina-py]]

Attachment: Bug 2066344 - Part 3: Add telemetry for opening the New Tab customize panel and its subpanels

Record in the newtab ping when the Customize panel opens, when one of
its subpanels opens and which one, and when "Explore more themes" is
clicked in the themes subpanel. The CustomizeMenu component records the
two open events at the point where the panel becomes visible, so every
way of opening it counts the same way, whether from the customize
button, a message, or the widgets context menu. The "Explore more
themes" button reports its click as a user event, the way the other
New Tab clicks reach the TelemetryFeed module.

The panel open reuses the SHOW_PERSONALIZE user event name, so the
seven entry points that already sent that event are changed to stop
sending it. Nothing was listening for the event before this patch, and
now that the TelemetryFeed module is aware of it, leaving those
dispatches in place would count every open twice.

Original Revision: https://phabricator.services.mozilla.com/D324869

Comment 16

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/5ed1f118840f
https://hg.mozilla.org/releases/mozilla-beta/rev/27fc1a5f14f6
https://github.com/mozilla-firefox/firefox/commit/83d953790b1f
https://hg.mozilla.org/releases/mozilla-beta/rev/0b6d48fd8c6a
https://github.com/mozilla-firefox/firefox/commit/49d480571c59
https://hg.mozilla.org/releases/mozilla-beta/rev/7f5f1ff0e965

Comment 17

[Gabi Cheta [:Gabi] Desktop QA]

Verified as fixed in Firefox 158.0a1 and Firefox 157.0b1 Windows 11x64, macOS 26 and Ubuntu 24.