UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36

Steps to reproduce the problem:
I am trying to figure out how to accurately assign every request to the precise tab URL it came from. This is harder than it seems; going off of tab ID is not enough as the document may have changed in the meantime.

Correctly attributing requests to top-level documents is clearly an issue that affects many Chrome extensions. If you visit a resource-rich page and then navigate away from the page while it's still loading, your privacy/ad blocking extension is likely to mis-report resources belonging to the previous site on the site you just navigated to. I could reproduce this problem with Ghostery, uBlock Origin, etc.

In Privacy Badger's case, this common problem is not just a visual nit. Since Privacy Badger learns from browsing, incorrect attribution can lead to incorrect blocking decisions.

Please see  issue 838242  for more background to this request.

What is the expected behavior?
I propose adding a (optional?) tabUrl property to the details object passed to chrome.webRequest listeners. This property will eliminate the guesswork and the workarounds.

What went wrong?
No such property exists.

The initiator property is not good enough since it points to iframe URLs when the request is from an iframe. It could also be "null" when the request doesn't belong to a render frame. We need a tab URL that just works regardless of how deeply nested the frame the request came from is, or whether the origin is "opaque" or not.

We also can't work around these limitations using the frameId property on the details object since these frame IDs could point at inline HTML frames that never go through chrome.webRequest. This means we can't reliably construct a frame hierarchy for documents.

Did this work before? No 

Does this work in other browsers? N/A

Chrome version: 67.0.3396.87  Channel: n/a
OS Version: 
Flash Version: