1521537 - [Content Blocking] Cookie is not detected after restart with "Restore previous session" checked

Status: RESOLVED WORKSFORME

(Firefox :: Protections UI, defect)

Description

[David Olah]

[Affected versions]
Firefox 66

[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 https://www.mozilla.org/en-US/firefox/download/thanks/
3. Cancel the download and observe that a cookie is blocked and shield icon appears.
4. Go to Options from Hamburger menu.
5. Check "Restore previous session"
6. Restart Firefox
7. The download popup will show by restore, cancel it again
8. Check the "Show more information" panel

[Expected result]
The same cookie is blocked and the shield icon appears.

[Actual result]
No cookie is detected and shiel icon is not displayed.

[Note]
You can see the before and after restart printscreens in the attachments.

Comment 1

[David Olah]

Attachment: Before_restart.png

Comment 2

[David Olah]

Attachment: After_restart.png

Comment 3

[(no longer active)]

I can't reproduce bug 1521488 so I have no way of testing this, but I can tell you what is happening here which is causing this behaviour: when the page is loaded after restart, it chooses not to embed a resource from https://ad.doubleclick.net so the Cookies subview shows nothing.

This is not is almost certainly not really a bug but rather the cookies subpanel is doing what it has been designed to do. Before we have another back and forth on whether the behaviour is confusing to the user etc please pay attention to what I'm saying here: the cookies subpanel is designed to show exactly what has happened on the page. When you restart the browser, we have no magical knowledge to tell us what exact elements were present the last time you loaded the page, so it is just telling you that this time no resource from https://ad.doubleclick.net was blocked as a third-party tracking resource. For example, if the web page had some code like:

if (Math.random() < 0.5) {
loadAdFromDoubleclick();
}

Then our cookies subpanel would show https://ad.doubleclick.net around 50% of the time the page loaded, since the ad loading behaviour of the page is randomized.

Whether or not this behaviour is desirable, understandable, etc is a completely separate question, and I agree that if a user follows the STR in comment 0 they may not understand why the second time the Cookies subpanel shows something different, but they may also think the second time the subpanel is showing them nothing because the second time no tracker was present, etc. That is a subjective interpretation which is probably different based on the level of understanding of each user of the concept of tracking elements on web pages. This is an advanced UI and I'm trying to explain here why I'm saying "this is not a bug" based on how the feature is designed to work.

FWIW in order to file a useful bug like this, what you should do is for example to have the network monitor loaded the second time you load the page, and demonstrate that a resource from https://ad.doubleclick.net is being served a cookie, or in web console demonstrate there is a message saying a cookie from https://ad.doubleclick.net is blocked, etc. If you see some evidence of the UI actually behaving differently from what goes on behind the scenes then that's a bug that we would be interested to know about and fix at this stage. Thanks!

Comment 4

[David Olah]

Thanks Ehsan for the explanation. I am closing the bug as WFM and if I manage to reproduce it the way you described I will reopen it.

Comment 5

[(no longer active)]

Thanks David!