On firefox, clicking links in tweets shows a false positive blocked t.co domain on the resulting page

[simonft]

When clicking a link on twitter, the link opens a t.co url in a new tab which redirects to the actual page. When using Privacy Badger on Firefox, a blocked t.co request will often be shown on the final page. E.g.:

This doesn't seem to happen with every link, thought it will pretty consistently happen for me with the links in these tweets:

https://twitter.com/PaulMitchum/status/1309920426152189952
https://twitter.com/varlogsimon/status/1309972367041585155

If I open the link with a middle click instead of a left click, the domain will only show up as blocked if I can click on the new tab before the redirect away from the t.co domain happens. Upon a refresh of the page, t.co no longer shows in the list of detected trackers.

I can't reproduce this in chrome.

I have no idea how any of this works under the hood but I'm guessing there's a race condition somewhere?

[bheerssen]

This happened to me also.

[ghostwords]

Hello and thanks for reporting this bug!

It looks like we sometimes see a request for https://t.co/favicon.ico after the request for the main document of the destination page. This makes Privacy Badger think t.co is present on the destination page.

This is related to #1997 and should be fixed when we come back to finishing #2198.

[ghostwords]

My guess is favicon fetching in Firefox has to do with how long it takes for t.co to redirect. Chrome doesn't ever seem to fetch the favicon in this situation. Regardless, Firefox extension APIs at this point provide enough information for us to recognize that the t.co favicon request originated from a t.co "page", and as such (A) doesn't belong to the current page and (B) is first-party and should be left alone.