1512141 - [Content Blocking] We don't dispatch STATE_COOKIES_BLOCKED_TRACKER when the response comes from the cache

Status: RESOLVED DUPLICATE of bug 1515343

(Firefox :: Protections UI, defect, P1)

Description

[Rares Doghi, Desktop QA]

Attachment: SneakyTrackingCookies.png

[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. Reach https://docs.google.com/document/ and open any document, or create one.
3. In the same tab reach www.reddit.com.
4. Check the Site Information panel - Tracking cookies blocked and check the Tracking cookies list.


[Expected result]
All Tracking cookies should be blocked as stated with the Standard option.

[Actual result]
Some TRacking cookies might still be allowed if the user reaches different pages in the same tab

[Note]
If the user reaches the reddit page directly with a fresh profile the above mentioned allowed cookie is BLOCKED, this issue only occurs when reaching reddit from the same tab a GOOGLE doc was opened.
I attached a log file created with set MOZ_LOG=AntiTracking:5 I hope it helps.

If that cookie is not a Tracking cookie it shouldnt be displayed in the Tracking cookie list or if Theres like 1st Party Cookies and 3rd Party Tracking cookies then 2 different categories should be displayed in the Cookies list from the Site info panel.

Comment 1

[Rares Doghi, Desktop QA]

Attachment: sneakyCookie.zip

Comment 2

[Tanvi Vyas[:tanvi]]

Is this because of our heuristics?  The navigation to reddit.com isn't via a window.open or anything like that, so heuristics don't really make sense.  Plus the allowed label isn't next to the cookie.  Are we for some reason capturing cookies from the previous page load?

Comment 3

[(no longer active)]

No, it is because googleads.g.doubleclick.net is cached from step 2, I'm pretty sure.  When this happens we don't dispatch the right notifications when we see a fetch to that resource on reddit.com.  This can be verified by keeping the network monitor open in step 3 of the STR in comment 0 to verify the response to the request to googleads.g.doubleclick.net is cached.

I had seen this bug before and forgot to file it.

Comment 4

[Tanvi Vyas[:tanvi]]

Note that in this case, the UI is lying and the cookies don't really get snuck in.  Marking as a P2.

Comment 5

[(no longer active)]

(In reply to Tanvi Vyas out until 11-26-18[:tanvi] from comment #4)
> Note that in this case, the UI is lying and the cookies don't really get
> snuck in.  Marking as a P2.

I'm not quite sure who's at fault here yet.  The bug may very well be in Gecko in fact.

Comment 6

[Rares Doghi, Desktop QA]

Please also note that the same thing occurs when the user starts firefox with a fresh new profile and reaches reddit. Its a giant list of Tracking cookies blocked and between them a few that are allowed from the same Tracking cookies category. Please see the attached file.

Comment 7

[Rares Doghi, Desktop QA]

Attachment: SnkeayCookies2.png

Comment 8

[(no longer active)]

(In reply to Rares Doghi from comment #6)
> Please also note that the same thing occurs when the user starts firefox
> with a fresh new profile and reaches reddit. Its a giant list of Tracking
> cookies blocked and between them a few that are allowed from the same
> Tracking cookies category. Please see the attached file.

Can you please file another bug for this case?  We may have a couple of different issues at play here...  Thanks!

Comment 9

[Erica Wright [:ewright]]

This may be related to bug 1510860

Comment 10

[Rares Doghi, Desktop QA]

Hi Ehsan, I tried to reproduce the issue I mentioned with the latest version of Nightly 66.0a1 (2018-12-11) and the Issue no longer occurs, I did perform a mozregression for it and it seems that Johann fix did the trick, here are the results from the mozregression:

First good revision: e7f045faf96d4d00a6caa058c5a26fd88946393a
Last bad revision: 324e00e894edd403d6a1a5ab439641b42807707d
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=324e00e894edd403d6a1a5ab439641b42807707d&tochange=e7f045faf96d4d00a6caa058c5a26fd88946393a

Let me know if you still need me to add a defect for the issue.

Comment 11

[Rares Doghi, Desktop QA]

Hi again, I came across this other website http://wot.wikia.com/wiki/The_Path_of_Daggers where if you load the page and Click the Reject Cookies in the site prompt, when you reach Cookies you will see some tracking Cookies blocked and some allowed. This was reproduced with a Fresh Profile. Do you want me to add a new defect for this issue ?

Comment 12

[(no longer active)]

(In reply to Rares Doghi from comment #10)
> Hi Ehsan, I tried to reproduce the issue I mentioned with the latest version
> of Nightly 66.0a1 (2018-12-11) and the Issue no longer occurs, I did perform
> a mozregression for it and it seems that Johann fix did the trick, here are
> the results from the mozregression:
> 
> First good revision: e7f045faf96d4d00a6caa058c5a26fd88946393a
> Last bad revision: 324e00e894edd403d6a1a5ab439641b42807707d
> Pushlog:
> https://hg.mozilla.org/integration/autoland/
> pushloghtml?fromchange=324e00e894edd403d6a1a5ab439641b42807707d&tochange=e7f0
> 45faf96d4d00a6caa058c5a26fd88946393a
> 
> Let me know if you still need me to add a defect for the issue.

That's the bug that added this subpanel, so this doesn't tell us anything interesting.  :-)

(In reply to Rares Doghi from comment #11)
> Hi again, I came across this other website
> http://wot.wikia.com/wiki/The_Path_of_Daggers where if you load the page and
> Click the Reject Cookies in the site prompt, when you reach Cookies you will
> see some tracking Cookies blocked and some allowed. This was reproduced with
> a Fresh Profile. Do you want me to add a new defect for this issue ?

baku is going to look at this issue, now we have several reproducible test cases, I guess let's wait for him to take a look and see what he thinks, if his fix only fixes some issues we can file follow-ups for the rest.  Thanks!

Comment 13

[(no longer active)]

Sorry to have duplicated any work, but I managed to find a much easier site where this problem would reproduce and found the underlying cause (turned out it was unrelated to HTTP cache!).  So I'm duping this against the other bug where I'm going to post a patch shortly.