Proposal: pass the tabId into the webRequest listener when the request starts in the tab, but is hijacked/completed in a SW.

[cthae]

Here is the context: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/T6i88oLU87Y

I'm not sure if it's even possible for the webextensions team to maintain the request details when SW hijacks it and resurface it in an elegant manner. But then there should still be a way for us to listen to them?

[bershanskiy]

I think I understand your use case, but I'm not sure I understand your proposal. I believe there are at least two possible solutions:

1. Attach initiator information (tabId/frameId/documentId) to requests initiated or served by service workers. For example, if page initiates request req1, then this request is routed to service worker handler for fetch event handler as event e and the handler transforms the response by initiating a separate request req2 and serving the response res2 to page by calling e.respondWith(), then the extension should get initiator information on all events of webRequest API.

2. Ensure there is an extension API for inspecting/intercepting requests initiated by the page before they are routed to fetch handler (be able to inspect/intercept req1 and req2 as separate events sharing a unique identifier).

Approach 1 seems to make a number of assumptions and edge cases. It would be easier for the developer for the most common case, but would be confusing for some rare cases. For example, service workers by design cache responses to requested resource and regularly prefetch other resources besides the requested one.

Approach 2 seems to require more work up-front (to keep track of the id within extension), but would more accurately represent the actual behavior of the page, the service worker, and the network.

[cthae]

Either solution would be eagerly welcomed if they're realistic to implement. Maybe having both of them at the same time would be the most comfy and covering thing.