1512166 - [Content Blocking] Cookies and Trackers are labeled as "blocked" in the Control Center even if Content Blocking is turned off for that site

Status: VERIFIED FIXED

(Firefox :: Protections UI, defect, P1)

Description

[Timea Cernea [:tbabos][inactive]]

[Affected versions]
Firefox 65.0a1 (2018-12-04)

[Affected platforms]
Ubuntu 16.04, Windows 7/10, Mac OS 10.13

[Steps to reproduce]
1. Open Firefox with a new profile
2. Go to dailymotion.com
3. Set Content Blocking to Strict in about:preferences#privacy 
4. Check the Control Panel section: Cookies and Trackers are blocked
5. Turn off blocking for this site

[Expected result]
The Cookies and Trackers should be displayed with a different label since tracking protection is disabled for that site. "Detected" would be a suggestion. 

[Actual result]
Cookies and Trackers are still labeled as "blocked".

[Note]
If the lists for both of them are reached, the listed cookies and tracker are not blocked even if the label from the control center suggested it.

Comment 1

[Tanvi Vyas[:tanvi]]

Betsy, Bryan - do you want to change the label next to "Cookies" and "Trackers" when a user has disabled protection on a page?  So that the labels don't say blocked, when in fact nothing is blocked?

Marking as P2 and we should aim for Firefox 66 for this, to avoid confusion.  In practice, we know the disable protection button isn't hit frequently so this confusing UI won't appear regularly.

Comment 2

[(no longer active)]

With bug 1511751, these labels are going away for now.

Comment 3

[Betsy Mikel [:betsymi]]

Awesome, thanks Ehsan. Was about to offer that as an option.

Comment 4

[Tanvi Vyas[:tanvi]]

We don't know if they are going away.  I'm hoping we get some user research resources to help us figure that out.  (I sent an email yesterday about the issue.)  Should we consider what happens if they don't go away?

Comment 5

[(no longer active)]

(In reply to Tanvi Vyas out until 11-26-18[:tanvi] from comment #4)
> We don't know if they are going away.  I'm hoping we get some user research
> resources to help us figure that out.  (I sent an email yesterday about the
> issue.)

Just to clarify, comment 2 was for Timea's benefit, since she wasn't in our meeting yesterday and I thought she might have been surprised to have found the labels being removed in Nightly in a day or two.  I didn't intend to start an argument about the labels in this bug.  :-)

> Should we consider what happens if they don't go away?

I don't know, but note that this bug is just _one_ case to consider where our labels don't match what we actually do and show in the subpanels, it's not the only one, as we previously discussed.  For Timea, here are some other examples:

  * When the user has a "cookie" permission on one or more third-party sites, those will be allowed to store cookies even if Content Blocking settings normally prevent that, so saying "Blocked" isn't accurate in all cases.
  * When the user uses a login form using Google/Facebook login for example, we grant automatic access to the login provider on the site they're logging in to, so saying "Blocked" isn't accurate in those cases.
  * When the user goes to a site where a third-party tracker calls the Storage Access API <https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Using> in order to obtain storage access, this may be allowed and then the "Blocked label isn't accurate any more.
  * When the user changes their Content Blocking settings as the page is loaded, the "Blocked" label may not be accurate any more.
  * ... (there are probably more cases I'm forgetting)

In short, for now these labels merely describe the setting you've selected in Preferences.  There are many possible cases that could occur here and in all but one of them (where what we have done matches 100% with the global settings) these labels are currently inaccurate!

Comment 6

[bbell]

Attachment: Artboard.png

Bring back the "type of blocking" label in the Control Center, and only hide is if a user has whitelisted the page. 

The label is important because it clarifies to the user that blocking is happening, and if it's happening what is it blocking. Without the label, the UI fails to deliver this context to the user.

Comment 7

[Tanvi Vyas[:tanvi]]

To add some more details:

browser.contentblocking.control-center.ui.showAllowedLabels remains false by default
browser.contentblocking.control-center.ui.showBlockedLabels switches to true by default

Regardless of the pref values, when a user has disabled protection for a site, we should hide the blocked/allowed labels in the main panel for both Trackers and Cookies.

Comment 8

[Tanvi Vyas[:tanvi]]

In Comment 5, Ehsan mentions other issues with the labels, other than cases where disable protection button is hit.  We aren't going to solve for these edge cases.  I can provide more details below.

(In reply to :Ehsan Akhgari from comment #5)
>   * When the user has a "cookie" permission on one or more third-party
> sites, those will be allowed to store cookies even if Content Blocking
> settings normally prevent that, so saying "Blocked" isn't accurate in all
> cases.
Yes, if the user adds a permission to the Cookies and Site Data section in Preferences for a tracking domain, than that tracking domain will be allowed and show up as unblocked in the subpanel even though the main panel says "Blocking Tracking Cookies".  We aren't going to solve for this discrepency, as Firefox still intends to block other tracking cookies on the page and saying "blocking some tracking cookies" or something like that could cause even more confusion. 

>   * When the user uses a login form using Google/Facebook login for example,
> we grant automatic access to the login provider on the site they're logging
> in to, so saying "Blocked" isn't accurate in those cases.
Yes, in those cases though the subpanel will explicity say "Allowed" with an X next to it.  So the user could block those instances.  Also, the subpanel is separate from the main panel - they are not both exposed at the same time.  So it may take a lot for a user to go through, parse the panels, and realize this discrepancy.

>   * When the user goes to a site where a third-party tracker calls the
> Storage Access API
> <https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Using>
> in order to obtain storage access, this may be allowed and then the "Blocked
> label isn't accurate any more.
Same as above.

>   * When the user changes their Content Blocking settings as the page is
> loaded, the "Blocked" label may not be accurate any more.
Yes, overall we do not handle refresh well.  It is an edge case that we should solve for in a followup bug.

Comment 9

[Erica Wright [:ewright]]

Attachment: Bug 1512166 - Show blocked labels by default, hide when there's an exception.

In the control panel, show the blocking category labels for tracking protection and cookie restrictions. Hide the label if the user has set an exception for that page.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7e75579b27d0
Show blocked labels by default, hide when there's an exception. r=nhnt11

Comment 11

[Erica Wright [:ewright]]

To test:

This should look like the mock in https://bugzilla.mozilla.org/show_bug.cgi?id=1512166#c6

For cookies only, we show a label with the type of cookie restriction category that has been set. This is regardless of whether we are blocking any cookies.

If there is an exception set for the page, we do not show the label.

1. go to https://www.ebay.com/
2. click the shield in the top left of the url bar
3. view the label beside the "cookies" list item
4. ** the label should show with the cookie setting you have ** 
4. change your cookie preferences by going to 'about:preferences' > privacy and security
5. refresh the original page
6. click the shield to open the panel
7. ** The label should have changed to show the new type of blocking you've chosen **
8. click "turn off blocking for this site"
9. click the shield again
10. ** the label should no longer show on that domain **

Comment 12

[Erica Wright [:ewright]]

Comment on attachment 9032963 [details]
Bug 1512166 - Show blocked labels by default, hide when there's an exception.

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: None

User impact if declined: User may be confused about what setting they have and if blocking is or is not happening.

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: steps described in https://bugzilla.mozilla.org/show_bug.cgi?id=1512166#c11

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): UI change, simple CSS change, and pref flip. The ui that shows as a result of the pref flip has already been tested.

String changes made/needed: none

Comment 13

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/7e75579b27d0

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9032963 [details]
Bug 1512166 - Show blocked labels by default, hide when there's an exception.

[Triage Comment]
Fixes some confusing UI in the Control Center. Approved for 65.0b8.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/c0660dad5c7e

Comment 16

[David Olah]

Verified on nightly 66.0a1 (2019-01-03) and Firefox 65.0b8.