2063963 - The number of blocked trackers in the widget is not always correct after opening a new tab page

Status: VERIFIED FIXED

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

Description

[Gabi Cheta [:Gabi] Desktop QA]

Attachment: 2026-08-14_17h15_16.mp4

Affected versions

• Firefox 156.0a1

Affected platforms

• Windows 11 x64
• macOS 14
• Ubuntu 24

Preconditions

• privacy widget enabled
• have some blocked trackers

Steps to reproduce

1. Refresh the new tab page to force update the number of blocked trackes
2. Close the tab
3. Open a new tab page
4. Observe the number of blocked trackers

Expected result

• The privacy widget number of blocked trackers should update accordingly

Actual result

• The number of blocked trackers in the widget is not always correct after opening a new tab page

Regression range
*New implementation

Additional notes

• The blocked trackers are updating correctly after a new tab page refresh
• See the attached screen capture

Comment 1

[Hackbot]

Triage / proposed fix plan (read-only investigation, not verified by running).

Root cause: a stranded count-up "hold" on a preloaded tab.

New tabs render while preloaded and hidden. When the feed broadcasts a pending count-up celebration to a hidden tab, browser/extensions/newtab/content-src/components/Widgets/Privacy/Privacy.jsx pins the readout at the pre-award number via hold(celebration.fromCount), so revealing the tab doesn't flash the final count. hold() sets animatedValue, and displayValue = animatedValue ?? value — see browser/extensions/newtab/content-src/components/Widgets/useCountUp.jsx — so from that moment the widget stops tracking trackersToday.

The hold is only dropped by the release() on Privacy.jsx#310, which is unreachable once the award goes away: if the award is withdrawn while the tab is still hidden, the next broadcast carries celebration: null, so isNewAward/isNewMoment are both false and the effect takes the bare early return at Privacy.jsx#267-269 without releasing. The readout stays frozen at fromCount for the life of the document — including after the tab is shown, since showing it re-runs the same effect down the same early return. Reloading remounts the component and clears animatedValue, which is why "it updates correctly after a refresh".

Two ways the award is withdrawn, both in browser/extensions/newtab/lib/Widgets/PrivacyFeed.sys.mjs: another (visible) tab plays it and acks it via WIDGETS_PRIVACY_MARK_CELEBRATED, clearing pending (#518-524), or it ages out of CELEBRATION_WINDOW_MS (#330-337). The first is exactly STR step 1: refreshing a newtab gives a visible tab that plays and acks the award, stranding the already-holding preloaded tab — which is what you then open in step 3. That also explains "not always": it only goes wrong when an award happened to be in flight.

Corroborating detail worth checking in the capture: only the large number should be wrong. The a11y copy (stableCount) and the "trackers blocked today / across sites" labels read trackersToday directly, so they stay correct while the big number is stale.

Secondary (independent) staleness. NEW_TAB_INIT fires when the tab is preloaded, not when it is displayed, so nothing re-reads the count at view time; a tab shown minutes after preload displays the preload-time count until the next SYSTEM_TICK (5 min). The updateMessage() comment at PrivacyFeed.sys.mjs#392-400 already flags this as the known preload/view-time follow-up.

Proposed fix

1. Primary: in the useLayoutEffect in Privacy.jsx, don't return without dropping a hold that can no longer be paid off — e.g. call release() on the !isNewAward && !isNewMoment path when there is no pending awardedAt. release() is already a no-op while an animation is running, so it can't interrupt a live count-up.
2. Optional hardening: have the hidden-tab branch re-hold() only while the award is still live, and/or refresh the count at view time (dispatch on first visibilitychange and let PrivacyFeed run updateCounts()), which also fixes the preload-time staleness above.

Tests: browser/extensions/newtab/test/jest/content-src/components/Widgets/Privacy.test.jsx has a "celebration on a preloaded tab" block that covers hold-while-hidden and the reduced-motion release, but not "award withdrawn while hidden" — that is the case to add. Also test/jest/content-src/components/Widgets/useCountUp.test.jsx and test/xpcshell/test_PrivacyFeed.js.

Severity: S3 — wrong value on a widget readout, no functional loss and a workaround in-product (reload the tab), but it undermines the widget's only number.

---

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]

I think this is expected, the tab must be refreshed to see the updated count

Comment 3

[Helen]

I retract my previous status from yesterday. I see the issue now. The STR are:

1. Open a new tab
2. Open another new tab, visit a site with trackers like www.usnews.com and wait for animation tracker to finish displaying
3. Go back to existing tab from step 1, refresh the page and take note of the # of trackers blocked, 137.
4. Open a another new tab page, observe the number of blocked trackers and the number is sometimes smaller than was previously shown. So less than 137 in my case.

It's not always reproducible tho. On new tab open, it should always have the latest # of trackers blocked. Not a launch blocker.

Comment 4

[Reem Hamoui]

I would say this is more of a general cache bug rather than the widget itself. Since it fixes itself on refresh I would deem this as a minimal issue that is fine to close.

Comment 5

[Gabi Cheta [:Gabi] Desktop QA]

(In reply to Reem Hamoui from comment #4)

I would say this is more of a general cache bug rather than the widget itself. Since it fixes itself on refresh I would deem this as a minimal issue that is fine to close.

I agree that the issue is not a launch blocker but I'm not sure that we should close it because refresh solves the issue. The widget displaying an incorrect number may still be user visible even if intermittent. I'd suggest keeping it open or tracking it as cache related issue.

Comment 6

[Gabriel H [:gharp, :gabriel]]

Reem, let's proceed with a fix that utilizes polling when the widget is on the page -- similar to what we used for the WCW.

Comment 7

[Reem Hamoui]

Hey Gabi, a few of us just attempted to reproduce this issue several times, but it seems to be working just fine on our end. Could you verify if it's still occuring on your end? If it's fixed, we could possibly close this, but let's definitely be sure first.

Comment 8

[Gabi Cheta [:Gabi] Desktop QA]

Attachment: 2026-08-21_10h15_52.mp4

Comment 9

[Gabi Cheta [:Gabi] Desktop QA]

(In reply to Reem Hamoui from comment #7)

Hey Gabi, a few of us just attempted to reproduce this issue several times, but it seems to be working just fine on our end. Could you verify if it's still occuring on your end? If it's fixed, we could possibly close this, but let's definitely be sure first.

Hi Reem, I am able to reproduce the issue with the latest Nightly 156.0a1 (2026-08-20). I've added a new screen recording.

Comment 10

[Reem Hamoui]

Attachment: Bug 2063963 - Fix tracker count refresh issue in Privacy widget. r=#home-newtab-reviewers

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/2a770946653f
https://hg.mozilla.org/integration/autoland/rev/a359803f8719
Fix tracker count refresh issue in Privacy widget. r=nina-py

Comment 12

[Silaghi Andreea]

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

Comment 13

[Silaghi Andreea]

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

Comment 14

[Gabi Cheta [:Gabi] Desktop QA]

Verified as fixed in Firefox 156.0a1 with Windows 11x64, Ubuntu 26 and macOS 14.

Comment 15

[Reem Hamoui]

Thanks for your help here Gabi!