1570430 - Tracking protection panel shows the wrong entry when an automatic storage access grant heuristic is triggered

Status: RESOLVED DUPLICATE of bug 1566825

(Firefox :: Site Identity, defect)

Description

[(no longer active)]

STR:

1. Go to https://www.pinterest.ca/. I tried this in a private window, but I don't believe the bug is specific to private windows.

At this point, the content blocking log looks like this (from the browser console):

await gBrowser.selectedBrowser.getContentBlockingLog()
"{
 \"https://www.pinterest.ca\": [[32768, true, 1]],
 \"https://accounts.pinterest.com\": [[32768, true, 1]],
 \"https://smartlock.google.com\": [[32768, true, 1]],
 \"https://apis.google.com\": [[8192, true, 1], [32768, true, 1], [536870912, true, 14]],
 \"https://connect.facebook.net\": [[4096, true, 1]],
 \"https://www.gstatic.com\": [[8192, true, 1], [32768, true, 1], [536870912, true, 2]],
 \"https://www.google.com\": [[8192, true, 1], [32768, true, 1], [536870912, true, 1]],
 \"https://accounts.google.com\": [[8192, true, 1], [32768, true, 1], [536870912, true, 185]],
 \"https://ssl.gstatic.com\": [[8192, true, 1], [32768, true, 1], [536870912, true, 3]]
}
"

2. Click on "Continue with Google". This will activate our automatic storage access grant heuristic. At this point our content blocking log looks like:

await gBrowser.selectedBrowser.getContentBlockingLog()
"{
 \"https://www.pinterest.ca\": [[32768, true, 1]],
 \"https://accounts.pinterest.com\": [[32768, true, 1]],
 \"https://smartlock.google.com\": [[32768, true, 1]],
 \"https://apis.google.com\": [[8192, true, 1], [32768, true, 1], [536870912, true, 14]],
 \"https://connect.facebook.net\": [[4096, true, 1]],
 \"https://www.gstatic.com\": [[8192, true, 1], [32768, true, 1], [536870912, true, 2]],
 \"https://www.google.com\": [[8192, true, 1], [32768, true, 1], [536870912, true, 1]],
 \"https://accounts.google.com\": [[8192, true, 1], [32768, true, 1], [536870912, true, 247], [536870912, false, 1, 2], [536870912, true, 55]],
 \"https://ssl.gstatic.com\": [[8192, true, 1], [32768, true, 1], [536870912, true, 3]]
}
"

Note the newly added [536870912, false, 1, 2] entry for accounts.google.com. That is the newly added content blocking log entry that is being mishandled here.

3. Now open the protections panel and open Cookies under it.

Actual Results:
https://accounts.google.com has a "x Blocked" label next to it.

Expected Results:
https://accounts.google.com must have a "x Allowed" label next to it.

Reloading the page at this point will make the bug go away.

We used to have this same bug in the browser-contentblocking.js code before, so I suspect that we probably have a logic bug similar to that one...

Comment 1

[(no longer active)]

(In reply to :Ehsan Akhgari from comment #0)

We used to have this same bug in the browser-contentblocking.js code before, so I suspect that we probably have a logic bug similar to that one...

That was bug 1514070, FWIW.

Comment 2

[(no longer active)]

Attachment: Screenshot

Comment 3

[(no longer active)]

This bug may be related to bug 1566825 (or in fact a duplicate of bug 1566825). I'm spending some time to debug that bug, will update here with more information...

Comment 4

[(no longer active)]

I confirmed that this is a dupe of bug 1566825.