1512137 - [Content Blocking] Trackers and Cookies lists in Control Center are not updated after changing blocking settings

Status: NEW

(Firefox :: Protections UI, defect, P3)

Description

[Timea Cernea [:tbabos][inactive]]

Attachment: Video of the issue

[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. In the Hamburger Menu, click Content Blocking
3. Set the Content Blocking option to Strict
4. Navigate to dailymotion.com
5. Check the list of blocked trackers and cookies - the blocked label should be on the right side of each blocked tracker and cookie
6. Change the Content Blocking setting to Standard and DO NOT refresh Dailymotion page
7. Check again the list of the "Allowed" Trackers and Cookies

[Expected result]
The trackers and cookies that are not blocked by the setting should be listed without any label in the list, as they are allowed.

[Actual result]
The trackers and cookies from the lists are still shown as BLOCKED since the lists are not updated after changing the content blocking setting. 

[Note]
The lists will be updated only after refreshing the page. Given that the labels beside Tracker and Cookies from the Control Center are updated instantly after switching the setting, the labels for the items in the lists should behave the same way or at least warn the user to refresh the page in order to apply the new content blocking option.

Comment 1

[Tanvi Vyas[:tanvi]]

The labels in the subpanel should probably remain the same until a refresh occurs.  But I agree it would be nice to inform the user that they need to refresh to apply the new settings that they just selected, instead of just switching the labels when the new labels don't apply to that page yet.  We would need a design for how to do that.  This is out of scope for Firefox 65.  Marking as P3 and flagging UX for a design.

Comment 2

[Betsy Mikel [:betsymi]]

Can we solve this for users without putting messaging in front of them? Is it absolutely necessary for them to refresh the page?

Comment 3

[(no longer active)]

This bug as filed is actually WONTFIX.

The Control Centre is designed to show what has happened on the page, as opposed to the settings that Firefox has been configured with.  In step 6 of your STR, nothing is changing for the Dailymotion page as far as the trackers that have already been loaded on the page go.  And the Control Centre reflects that reality 100% correctly, so in step 7 when you see these lists not changing, Firefox is telling you exactly what is happening on the page (that nothing is changing before you refresh the page.)  If the page loads content dynamically and you readjust your Content Blocking settings dynamically then that would impact what happens to the page in terms of blocking, and that would be correctly reflected in the Control Centre as well, so for example if the Dailymotion page was in the middle of loading when you changed settings, in Step 7 you'd see that some trackers were blocked (those loaded after you switched to Strict mode) while others weren't.

This is all working as designed and I don't think we'd want to change any of this.

FWIW when taking the suggestion in comment 1 into account (changing the Control Centre design to tell the users to refresh the pages to see the effect of a change in settings), I suggest first pausing and thinking about why we want to do that at all.  The vast majority of browser sessions would never include a change in these settings and as I mentioned above the Control Centre is faithfully showing accurate information about what's happened on the page even in that case.  Add to that the fact that most users have a short session life span, and the fact that the code for the Control Centre is currently stateless and it would be nice to not have to keep track of what content blocking settings were in effect all the time just so that we can display this warning message that almost no real user will ever see in practice.

That sounds to me like adding a lot of complexity to this code for almost no gain.  My recommendation is to WONTFIX the bug and move on.  In the off chance that I'm missing something and this is indeed a problem that real users will run into we'll get bug reports from users and we can reconsider when that happens.

Comment 4

[Rares Doghi, Desktop QA]

Hi Ehsan, we agree that the Lists Show what they are already doing in the page, the problem with this is that If a user reaches dailymotion and sees a bunch of cookies allowed and then decides to set the Option to STRICT or even CUSTOM to block ALL cookies when he reaches dailymotion in the prvious tab and checks the site information panel.. he will see All cookies blocked, he might not even check the lists to see that all the cookies previously loaded are actually allowed and when he scrolls down he might see a bunch of cookies he thought he already blocked.

Is this ok to happen? "nothing is changing for the Dailymotion page as far as the trackers that have already been loaded on the page go." but the labels for STRICT and what should be blocked ARE in fact changing in the Site information panel.

Comment 5

[(no longer active)]

(In reply to Rares Doghi from comment #4)
> Hi Ehsan, we agree that the Lists Show what they are already doing in the
> page, the problem with this is that If a user reaches dailymotion and sees a
> bunch of cookies allowed and then decides to set the Option to STRICT or

FWIW the Strict setting *only* blocks cookies from trackers.  Exactly like Standard, no difference there.

> even CUSTOM to block ALL cookies when he reaches dailymotion in the prvious
> tab and checks the site information panel.. he will see All cookies blocked,
> he might not even check the lists to see that all the cookies previously
> loaded are actually allowed and when he scrolls down he might see a bunch of
> cookies he thought he already blocked.

Right.  I agree that this is the behaviour that Firefox will have.

> Is this ok to happen? "nothing is changing for the Dailymotion page as far
> as the trackers that have already been loaded on the page go." but the
> labels for STRICT and what should be blocked ARE in fact changing in the
> Site information panel.

Yes, I think this is 100% fine.  Two points to note: Firstly it doesn't really make much sense to "block" cookies from a page that is already loaded, since the document.cookie API <https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie> might be used by the page to just set the cookies that you just blocked again.  So any meaningful way for the browser to block cookies from a page actually requires the settings to be set in the browser *before* you navigate to the page.

Secondly, we have a lot of evidence to suggest that most users do not change their privacy settings.  We probably wouldn't expect more than 1-2% of users to be looking at the Content Blocking UI in preferences and making changes there.  From that tiny minority of our users, yet another tiny subsection would potentially run into the confusion scenario that you described above.  As I mentioned in comment 3, Tanvi's suggestion in comment 1 requires us to keep track of the state of what Content Blocking settings were available at all times for the Control Centre UI which makes this code which currently works in a stateless fashion (i.e. without keeping track of any state for anything) quite a bit complex.

To summarize, we are talking about a potential edge case where user *maybe* get confused and the idea we have for fixing it *will* make our code more complicated.  And so far we have *no* evidence of users complaining about it at all.  Based on the data we have and what we know about how we can address this issue, my recommendation is WONTFIX until we gain some evidence that real users are finding this confusing and this is indeed a problem worth addressing.

Comment 6

[Tony Cinotto [:tcinotto] (UTC-8)]

Design to consider.

Comment 7

[Eric Pang [:epang] UX]

I believe this will be helped with the cookie policy change Baku proposed. I've created a spec and added a reload tabs button (in the event that cookie prefs have been changed) to let the user know they need to reload their open tabs for changes to take effect. This change only affects cookie prefs but can potentially be expanded to trackers as well.

https://mozilla.invisionapp.com/share/8MQF2R5HSR4#/345784770_Preferences

Comment 8

[Johann Hofmann [:johannh]]

I agree with Ehsan on the general idea here, this is an edge case that we don't have proof is really that confusing and fixing it would be complex.

I also think Eric is right that the reload UI for about:preferences could help with this (maybe not completely solve it, though).

For this reason we'll leave this in our backlog as P3, to monitor if this is actually a problem for more users and to revisit if we find a different angle to approach this from.