1491453 - Do not show inactive content blocking categories in the control centre

Status: RESOLVED WONTFIX

(Firefox :: Site Identity, enhancement, P1)

Description

[(no longer active)]

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.)

Comment 1

[(no longer active)]

Attachment: Bug 1491453 - Part 1: Only show categories under Content Blocking in Control Centre when something actually gets blocked in that category; r=johannh

Comment 2

[(no longer active)]

Attachment: Bug 1491453 - Part 2: Remove the now unused prefs that used to control the visibility of these categories; r=johannh

Depends on D5937

Comment 3

[(no longer active)]

Attachment: Bug 1491453 - Part 3: Remove the 'Add Blocking…' label from the three Content Blocking categories since it won't ever be displayed again; r=johannh

Depends on D5938

Comment 4

[Johann Hofmann [:johannh]]

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 :)

Comment 5

[Johann Hofmann [:johannh]]

> 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?

Comment 6

[(no longer active)]

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.

Comment 7

[(no longer active)]

This should probably be closed with the new design of the control centre for 65.

Comment 8

[Johann Hofmann [:johannh]]

(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.

Comment 9

[(no longer active)]

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."

Comment 10

[(no longer active)]

Unassigning myself at least.  I don't understand how the new UX spec is calling for this.  :-)

Comment 11

[Johann Hofmann [:johannh]]

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.