Rapid navigation mis-attributes previous page's resources to current page
Picking up from https://github.com/EFForg/privacybadger/pull/1642#issuecomment-328681731.
You can see this issue if you visit a page with lots of third-party resources (say, nytimes.com) and then quickly navigate away to another page (might help for it to be one with nothing on it, say, example.com). If you run into this bug, you'll see resources from the previous page reported as present on the new page. This leads to Privacy Badger incorrectly recording tracking by domains (on pages where those domains may not be present on).
Privacy Badger relies on main_frame resources inside a chrome.webRequest.onBeforeRequest listener to mark the start of bookkeeping for the new site URL (and the end of bookkeeping of whatever it previously had for the tab). However, it appears that the main_frame request does not always mark a clean boundary between pages; requests from the previous page sometimes show up after the main_frame request for the new page, such as when you navigate away from a busy page in the midst of loading.
There is a Chromium bug concerning unexpected ordering of chrome.webNavigation.onCommitted and chrome.webRequest.onBeforeRequest events, related to but not the same as this issue (as here the sequencing issues are within a single listener).
Filed crbug.com/838242 to get help with a related issue where some requests come with unknown-to-Privacy Badger frame IDs.
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1470537 to get help with the same unknown frame ID issue from Mozilla.
This is probably a blocker for issues like #1514 (any issue where we want to do something to all third-party requests).