requests intercepted by services workers do not complete the request flow
Categories
(WebExtensions :: Request Handling, defect, P3)
Tracking
(Not tracked)
People
(Reporter: mixedpuppy, Unassigned)
References
Details
While fixing the stream filter in Bug 1595197, I noticed that after a redirect by a service worker, we no longer receive further events.
Using dom/serviceworkers/test/test_streamfilter.html
Add webrequest listeners for the whole flow. Once you see the onBeforeRedirect event, you'll get another onBeforeRequest event (as expected) but you will not see any response events (e.g. onHeadersReceived, onCompleted)
|
||
Comment 1•5 years ago
|
||
|
||
Comment 2•5 years ago
|
||
would you mind to test if this works with "dom.serviceWorkers.parent_intercept" set to true and only broken when it is set to false?
|
||
Comment 3•5 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
Reporter | |
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 4•5 years ago
|
||
dom.serviceWorkers.parent_intercept makes no difference. In the existing test you'll note that filter.onerror is not fired for service worker intercepts, which means we do not see the redirect happen. More importantly, we do not see any further events like webRequest.onCompleted. The request becomes invisible to extensions.
Bug 1576769 seems to be the opposite of this issue.
Maybe asuth has a thought on this.
|
|
Reporter | |
Comment 5•5 years ago
|
||
Essentially, we don't get the response part of the request if a service worker does:
onfetch = e => {
e.respondWith(new Response(String("hi")));
};
|
||
Comment 6•5 years ago
|
||
The general synthesized response situation for parent intercept is:
- nsHttpChannel::RedirectToInterceptedChannel creates an InterceptedHttpChannel and redirects to it. This is where things probably get wacky for webRequest.
- The RespondWith result is processed in the parent process main thread
- If the response headers indicate a redirect that should be followed, control flow transitions to FollowSyntheticRedirect
- There's also a more subtle situation where a Response indicates a URL that's different than the fetch URL and an internal redirect is performed but we already have the synthesized response from the Response, handled by RedirectForResponseURL.
I think I started to understand the stream filter a bit during the previous work Perry was doing, but it's fallen out of my head and I can't find any high level implementation documentation in https://searchfox.org/mozilla-central/source/toolkit/components/extensions/webrequest or linked from there to quickly get context. Presumably the change to use new stream filters on redirect rather than trying to propagate the stream filter forward on redirect is dependent on an observer notification that is never fired for the successor channel that's an InterceptedHttpChannel? (I may be confused about the change too...)
|
|
Reporter | |
Comment 7•5 years ago
|
||
This doesn't have anything to do with the streamfilter, which may also be a (separate) issue.
This is about the http-on-* notifications that httpChannel issues, nsIHttpActivityObserver (for webRequest.onErrorOccurred) and nsIChannelEventSink (for webRequest.onBeforeRedirect). I think that onBeforeRedirect is working, it's the flow after that which is going to largely be the http-on-examine-* notifications.
There isn't necessarily a one-to-one translation for these, but you can see the setup[1] and handling [2] of the notifications.
[1] https://searchfox.org/mozilla-central/rev/ea7f70dac1c5fd18400f6d2a92679777d4b21492/toolkit/components/extensions/webrequest/WebRequest.jsm#551-595
[2] https://searchfox.org/mozilla-central/rev/ea7f70dac1c5fd18400f6d2a92679777d4b21492/toolkit/components/extensions/webrequest/WebRequest.jsm#631-648
Description
•