[Content Blocking] Cookies' labels are no longer displayed in the Control center after a restart/opening and closing the browser

VERIFIED FIXED in Firefox 65

Status

()

defect
P1
normal
VERIFIED FIXED
5 months ago
4 months ago

People

(Reporter: ciprian_georgiu, Assigned: johannh)

Tracking

Trunk
Firefox 66
Points:
---

Firefox Tracking Flags

(firefox64 disabled, firefox65+ verified, firefox66+ verified)

Details

(Whiteboard: [privacy65])

Attachments

(1 attachment)

Affected versions

  • latest Nightly 66.0a1
  • Beta 65.0b9

Affected platforms

  • Windows 10 x64
  • macOS 10.13
  • Ubuntu 16.04 x64

Steps to reproduce

  1. Launch Firefox.
  2. Go to about:preferences, to the "Content Blocking" section from Privacy & Security
  3. Click on the radio button next to "Custom" and check Cookies.
  4. Access https://www.reddit.com/.
  5. Restart the browser.
  • inspect the Cookies' label inside the information panel

Expected result

  • "Blocking Tracking Cookies" label is displayed in the information panel.

Actual result

  • "Blocking Tracking Cookies" label is NOT displayed in the information panel.

Regression range

  • Not a regression since I was able to reproduce it on 65.0b8 as well, when the Cookies' labels have been implemented.

Additional notes

Assignee

Updated

5 months ago
Whiteboard: [privacy65][triage]
Assignee

Comment 1

5 months ago

[Tracking Requested - why for this release]:
UI weirdness in the control center for new cool feature

Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [privacy65][triage] → [privacy65]
Assignee

Comment 2

5 months ago
This was causing some prefs that blockers were accessing not to be set yet.

Comment 3

5 months ago
Pushed by jhofmann@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5841878be567
Add lazy pref getter for content blocking before initializing blockers. r=ewright

Comment 4

5 months ago
bugherder
Status: ASSIGNED → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 66

This issue is verified fixed using Firefox Nightly 66.0a1 (BuildId:20190111041510) on Windows 10x64, Ubuntu 18.04x64, macOS 10.13, and Windows 7x64

Status: RESOLVED → VERIFIED

Please request Beta approval on this when you get a chance.

Flags: needinfo?(jhofmann)
Assignee

Comment 7

4 months ago

Comment on attachment 9035668 [details]
Bug 1519137 - Add lazy pref getter for content blocking before initializing blockers. r=ewright

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: Bug 1511954

User impact if declined: Parts of the content blocking UI are missing

Is this code covered by automated tests?: No

Has the fix been verified in Nightly?: No

Needs manual test from QE?: Yes

If yes, steps to reproduce: See comment 0

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): Very simple front-end patch that just moves a few lines of code higher up

String changes made/needed: None

Flags: needinfo?(jhofmann)
Attachment #9035668 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9035668 [details]
Bug 1519137 - Add lazy pref getter for content blocking before initializing blockers. r=ewright

[Triage Comment]
Fixes missing parts of the revamped content blocking UI shipping in 65. Approved for 65.0b11.

Attachment #9035668 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

This issue is verified fixed using 65.0b11(Build ID:20190112234105) on Windows 10x64, Ubuntu 18.04x64, macOS 10.14, and Windows .7x64

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.