2063525 - Missing ETP OFF state on the Privacy widget

Status: RESOLVED FIXED

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

Description

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Attachment: ETP off privacy widget.png

Affected versions

• Firefox 156.0a1 (2026-08-13)

Affected platforms

• Windows 11
• macOS 27
• Ubuntu 26.04

Preconditions

• Have some blocked trackers

Steps to reproduce

1. Observe the widget number of trackers blocked
2. Turn off the ETP in about:preferences#privacy
3. Refresh the new tab page and see the privacy widget

Expected result

• A warning stating that ETP is OFF is shown and a prompt to redirect the user to enable it is available

Actual result

• The widget remains the same as before, showing the number of blocked trackers

Regression range

• New feature

Additional notes

• The issue can be seen in the attachment

Comment 1

[Hackbot]

Triage / fix plan (static analysis, not verified by running).

Root cause: the ETP-OFF state was never implemented — this isn't a state that regressed, it's one that has no code anywhere. The whole newtab tree has zero references to etp / trackingprotection / contentblocking outside a test-setup line, and no newtab-privacy-etp-off* Fluent string exists yet. Concretely, at all four layers:

• browser/extensions/newtab/lib/Widgets/PrivacyFeed.sys.mjs — the ctx it hands the scheduler carries counts, totals, streak and feature flags, but no protection-enablement signal.
• browser/extensions/newtab/lib/Widgets/PrivacyMessages.sys.mjs — the precedence ladder starts at EMPTY; there is no ETP-off rung and no such CATEGORY.
• browser/extensions/newtab/common/Reducers.sys.mjs — INITIAL_STATE.PrivacyWidget has no protection-state field.
• browser/extensions/newtab/content-src/components/Widgets/Privacy/Privacy.jsx — isEmptyState = trackersToday === 0 and variant are the only branches.

So with ETP off the widget keeps rendering today's already-recorded TrackingDB total unchanged, exactly as reported.

Proposed approach (feed-side, matching how every other privacy-widget signal already flows):

1. In PrivacyFeed, compute an etpEnabled/protectionsOff boolean by mirroring the notBlocking check about:protections already uses — browser/components/protections/content/protections.mjs (cookieBehavior + tp/cryptomining/fingerprinting/socialtracking prefs). Note browser.contentblocking.category == "custom" alone is not sufficient — there is no "off" category. Read the prefs directly in the parent, as the widget already does for browser.ipProtection.enabled at PrivacyFeed.sys.mjs, and ship it on the existing WIDGETS_PRIVACY_UPDATE broadcast (the reducer already spreads ...action.data, so only the initial-state entry is needed). Add a Services.prefs observer for those prefs so a live toggle updates without a restart — the current PREF_CHANGED path only sees the activity-stream. branch.
2. In PrivacyMessages, add an ETP_OFF_MESSAGE constant outside PRIVACY_MESSAGES (modelled on EMPTY_MESSAGE) with variant: "etpOff", and return it before the EMPTY check so it outranks the zero state and every celebration. Give it an OPEN_PREFERENCES_PAGE CTA (category: "privacy-trackingprotection") for the "turn it back on" prompt. Also wire it into forcedResult()/variantForCategory() so QA can force it.
3. In Privacy.jsx, make the render at Privacy.jsx a three-way (isEtpOff ? … : isEmptyState ? … : …) so the ETP-off card suppresses both the count block and the empty state; add an is-etp-off class hook and style it next to .privacy-empty in _Privacy.scss.
4. New strings in browser/locales/en-US/browser/newtab/newtab.ftl (warning + -cta).

Worth auditing while there: the impression at Privacy.jsx would log an ETP-off view as an ordinary trackers_blocked = "none" day.

Tests: existing coverage is test/xpcshell/test_PrivacyFeed.js, test/jest/lib/Widgets/PrivacyMessages.test.js and test/jest/content-src/components/Widgets/Privacy.test.jsx. There is no browser-chrome coverage for this widget at all, so the new state should add cases to the three above.

Severity: S3 suggested — a new-feature state that is missing rather than broken; the count keeps rendering (misleading, but the user can still reach about:protections and about:preferences). Not cosmetic, but no crash, data loss, or blocked workflow. Nightly-only so far.

---

If you'd like to provide feedback on this comment, please use the 👍 or 👎 reaction.
If you want to categorize your feedback you can add one of the following tags: ai-triage-wrong-file, ai-triage-wrong-cause, ai-triage-hallucination, ai-triage-out-of-scope.

Comment 2

[Helen]

This use case wasn't included in the initial scope, so it won't be considered as a launch blocker. We'll address it in a post-launch iteration.

Comment 3

[Helen]

Less than 1% of Desktop FF have ETP completely turned off, downgrading priority.

Comment 4

[Reem Hamoui]

Attachment: Bug 2063525 - Add ETP off state for privacy widget. r=#home-newtab-reviewers

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/10bc3a111955
https://hg.mozilla.org/integration/autoland/rev/8bbcc957f1de
Add ETP off state for privacy widget. r=fluent-reviewers,nina-py,bolsson

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/786df994607e
https://hg.mozilla.org/integration/autoland/rev/ea2171d6d745
Revert "Bug 2063525 - Add ETP off state for privacy widget. r=fluent-reviewers,nina-py,bolsson" for causing newtab failures

Comment 7

[pstanciu]

Backed out for causing newtab failures

• https://hg.mozilla.org/integration/autoland/rev/ea2171d6d745748c1aca8d6677883b59db15a230
• Push with failures
• Failure Log

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/236231dec232
https://hg.mozilla.org/integration/autoland/rev/b31752a567b3
Add ETP off state for privacy widget. r=fluent-reviewers,nina-py,bolsson

Comment 9

[Silaghi Andreea]

https://hg.mozilla.org/mozilla-central/rev/b31752a567b3

Comment 10

[Silaghi Andreea]

https://hg.mozilla.org/mozilla-central/rev/b31752a567b3