Closed Bug 1491453 Opened 2 years ago Closed 2 years ago

Do not show inactive content blocking categories in the control centre

Categories

(Firefox :: Site Identity, enhancement, P1)

enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: ehsan, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [privacy65][triage])

Attachments

(3 obsolete files)

In Firefox 63, we show the categories based on whether they are enabled through their prefs.

For Firefox 64, we'd like to switch this to showing them based on whether something has been blocked currently in that category (IOW, whether that category is active.)
Priority: -- → P1
The way you approach this looks fine but there's one thing that I'm sure we originally specified but which is not considered in your code: We want to be able to show "Add Blocking" for blockers that are disabled but there was content detected on the page which could have been blocked.

I remember Bryan mentioning this requirement repeatedly, but we can also ask him to be sure. (Would have been cool to have a spec for this).

For FastBlock and TP that probably means just checking if trackers are present, I don't know whether you already have a mechanism for detecting the equivalent in Cookie Restrictions, though.

Unfortunately changing this would affect all 3 patches, so I have to cancel review on all of them until we have that figured out.

Let me know what you think :)
> We want to be able to show "Add Blocking" for blockers that are disabled but there was content detected on the page which could have been blocked.

Bryan, is that correct or did I make this up?
Flags: needinfo?(bbell)
I think I have to meet with Bryan about this.  We don't have the platform support for detecting when these things would be blocked, and for some categories (e.g. third-party cookies) that basically boils down to "when any third-party cookie is present".  So a design that wants to show Add Blocking when there is content that could be blocked but isn't blocked right now is, in practice, not all that different from what we already have implemented.

I think the design here needs to take the implementation aspects into account.
Whiteboard: [privacy-panel-64]
Whiteboard: [privacy-panel-64] → [privacy-panel-64][triage]
Whiteboard: [privacy-panel-64][triage] → [privacy-panel]
This should probably be closed with the new design of the control centre for 65.
(In reply to :Ehsan Akhgari from comment #7)
> This should probably be closed with the new design of the control centre for
> 65.

Looking at the more detailed specs in https://docs.google.com/document/d/1oaQUNlmfew5eTS0t9F2yq655i5Vc604ObxMN_kNswqc it seems to me like this is actually still required. For example:

User in normal or private browsing window visits a webpage with trackers and/or 3rd party cookies:
Address bar displays: Shield
Control Center: 
Type: Custom
Status: Blockable content detected
Trackers - Blocking if detected, Do not display if not detected
Cookies - Add Blocking if detected, Do not display if not detected
Button - Turn off blocking for this site

The difference is that now we want to show categories when they are _detected_ vs. always.
Status: NEW → ASSIGNED
Whiteboard: [privacy-panel] → [privacy65][triage]
Did you see my comments on the doc?  Not sure how to link to it.

I'll paste it here.

> Cookies - Add Blocking if detected, Do not display if not detected

This doesn't match Bryan's latest mocks. There, we need to display "cookies from this site."
Unassigning myself at least.  I don't understand how the new UX spec is calling for this.  :-)
Assignee: ehsan → nobody
Status: ASSIGNED → NEW
We found that this is not necessary with the new design and there was some confusion on what this bug is intended to do, so I filed bug 1506048 for the part that we actually want to do.
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(bbell)
Resolution: --- → WONTFIX
Attachment #9009339 - Attachment is obsolete: true
Attachment #9009340 - Attachment is obsolete: true
Attachment #9009341 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.