2041077 - manage cookies and site data empty

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect, P3)

Description

[zlice]

Attachment: cache.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:153.0) Gecko/20100101 Firefox/153.0

Steps to reproduce:

try to clear specific site cookies

Actual results:

nothing is listed (see attachment)

Expected results:

search through sites and clear specific caches.

i haven't used this in a while so i have no clue when this changed. i was still able to go to a site, click the shield-check next to the urlbar and clear cookies that way.

also i have firefox remove site cookies on close and a list of sites to keep.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking: Cookies' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Kershaw Chang [:kershaw]]

This is the regression range:
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=5d85334c95eda979785d121004aa4a8ee310deb4&tochange=cdabc42428fa68fd62d2c05537373e8ae409a194

I think this is likely caused by bug 2034243.
Emma, could you take a look? Thanks.

Comment 3

[Emma Zühlcke [:emz]]

Attachment: Bug 2041077 - Trigger SiteDataManager.updateSites on paneSearchResults too. r?mstriemer

The previous fix for bug 2034243 moved updateSites() into a one-shot paneshown
listener gated on category === "panePrivacy". When the user reaches the privacy
pane's settings via the search-results pane, gotoPref dispatches paneshown for
paneSearchResults, not panePrivacy, so updateSites never runs and the "Manage
Cookies and Site Data" dialog opens with an empty list.

Call updateSites directly at module load instead. The module is imported by
setting-pane.init() (redesign) or by the eager import in privacy.js (legacy),
so this fires exactly once per prefs document regardless of how the privacy
settings are surfaced.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/466d7cc2d506
https://hg.mozilla.org/integration/autoland/rev/d61571b973c6
Trigger SiteDataManager.updateSites on paneSearchResults too. r=mstriemer

Comment 5

[rperta]

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

Comment 7

[Mark Striemer [:mstriemer]]

We just got a duplicate of this for 152, perhaps we should consider uplifting to a dot release?

Comment 8

[Emma Zühlcke [:emz]]

I'm not opposed to it - it's a pretty simple change. At the same time only one path to the control is affected (the search) so a workaround exists.

Comment 9

[Emma Zühlcke [:emz]]

[Tracking Requested - why for this release]: Might be a good candidate for a dot-release ride along. Not critical.

Comment 10

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2034243

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Just nominate the patch for uplift if you want it to be considered for a dot release. It doesn't need to be tracking+ first.

Comment 12

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: In preferences when searching for site data the site data table will stay empty making it impossible to manage site data this way. Workaround: navigate to manage site data via the sidebar.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: 1. Go to about:preferences

2. In the search bar enter "clear data for specific sites"
3. Click the button "clear data for specific sites"

Expected result:
The manage site data table opens and shows site data entries

Actual result:
The manage site data table opens but there are no site data entries, even though there is site data present.

• Risk associated with taking this patch: low
• Explanation of risk level: Small production code change with test coverage.
• String changes made/needed?: no
• Is Android affected?: no

Comment 13

[Emma Zühlcke [:emz]]

Attachment: Bug 2041077 - Trigger SiteDataManager.updateSites on paneSearchResults too.

The previous fix for bug 2034243 moved updateSites() into a one-shot paneshown
listener gated on category === "panePrivacy". When the user reaches the privacy
pane's settings via the search-results pane, gotoPref dispatches paneshown for
paneSearchResults, not panePrivacy, so updateSites never runs and the "Manage
Cookies and Site Data" dialog opens with an empty list.

Extend the paneshown listener to also fire on paneSearchResults, matching the
pattern used in downloads.mjs.

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

Comment 15

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/a069b97d70b0
https://hg.mozilla.org/releases/mozilla-release/rev/2dd9f29b4036

Comment 16

[Monica Chiorean]

I was able to reproduce the issue on Win11 using Firefox build 152.0 and site https://www.prosport.ro, nothing was displayed on manage cookies and site date dialog.
Verified as fixed on Win11/Ubuntu 24.04/ Mac15.5 using Firefox builds 153.0b5 and 154.0a1.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Added to the 152.0.4 relnotes.

Comment 19

[Monica Chiorean]

Verified as fixed on Win11/Ubuntu 24.04 using Firefox build 152.0.4.