It seems that these stuff aren't really needed because whatever
reaches to here either successfully synthesized requests or requests
with system principal (ie: the requests we manually created in
test_synthesized_response.js).
If those conditions are true, then these ORB checks will have no
effect, so we can remove them.
Differential Revision: https://phabricator.services.mozilla.com/D161358
Since in D159582, the original HttpChannelChild/HttpChannelParent is reused instead of creating a new one. We need to clean up the StreamFilters which are already attached.
In original logic, this would be handled when StreamFilterParent::OnStartRequest is called(). By comparing the stored StreamFilterParent::mChannel and nsIRequest passed into StreamFilterParent::OnStartRequest, StreamFilterParent can know if the redirection happens or not, such that StreamFilterParent can decide should disconnect or not in OnStartRequest(). However, after D159582, since HttpChannelChild is reused, the logic would not work for ServiceWorker fallback redirection.
Opening the new nsHttpChannel in the parent process makes StreamFilters be attached to the original HttpChannelChild again, and it would send duplicate messages (OnStartRequest, OnDataAvailable, OnStopRequest) to the extension. So we need to remove the previous attached StreamFilters before opening the new channel.
In this patch, we introduce a new IPC method PHttpBackgroundChannel::DetachStreamFilters to inform the corresponding HttpChannelChild to disconnect StreamFilters. Unfortunately this introduces that HttpChannelChild needs to keep weak references of StreamFilters since we have no way to traverse the HttpChannelChild's listener chain and do special handling in StreamFilterParent only.
Depends on D159582
Differential Revision: https://phabricator.services.mozilla.com/D160203
ServiceWorker fallback(Reset interception) is a trivial redirection, it only changes the load flag nsIChannel::LOAD_BYPASS_SERVICE_WORKER. For this kind of redirection, we have a chance to avoid complicated redirection propagation by reusing the existing HttpChannelChild/HttpChannelParent directly to improve the performance of ServiceWorker fallback.
In this patch, we add
1. bool value InterceptedHttpChannel::IsReset to indicate if this is a fallback from ServiceWorker.
2. Instead of sending redirection to the content process, relinking the new nsHttpChannel directly in HttpChannelParent, such that HttpChannelParent/HttpChannelChild(and HttpBackgroundChannel IPCs) can be reused.
Differential Revision: https://phabricator.services.mozilla.com/D159582
This patch starts to actually blocking opaque responses
for most type of the resources that are defined in the spec.
There are still pieces missing such as blocking JSON responses,
and this is why it's called partially implemented.
This patch was originally written by farre, and I made some
modifications based on it.
Depends on D155128
Differential Revision: https://phabricator.services.mozilla.com/D155129
Everywhere except one loadInfo is supplied to an HTTPChannel
right after it is Init()-ed. Inside of Init we would like to
use the loadInfo so we'll put it in there.
Differential Revision: https://phabricator.services.mozilla.com/D144580
It is an edge case that InterceptedHttpChannel::Cancel() could be called before calling AsyncOpenInternal().
In the case, mTimeStamp status would be Created and we should not record any time stamp for InterceptedHttpChannel.
Differential Revision: https://phabricator.services.mozilla.com/D134775
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
Currently, soft reload uses the `VALIDATE_ALWAYS` flag to not only
force revalidate the top level document, but also subresources.
This causes content to be refetched from the web even if there
are caches that are still valid and can be used.
Chrome already has such behaviour to not revalidate all resources.
Differential Revision: https://phabricator.services.mozilla.com/D122270
Requests may be canceled before AsyncOpen is even called. In that case
we don't want to add START markers, and we don't want to add CANCEL
markers for these requests that didn't even start yet.
Depends on D123255
Differential Revision: https://phabricator.services.mozilla.com/D123256
This patch tries to record the fetch event dispatching time, the response's synthesizing time, and interception resetting time.
Fetch event dispatching time is the time duration between interception starts, which is the time point of InterceptedHttpChannel::AsyncOpenInternal(), and the fetch handler starts. It includes the InterceptedHttpChannel setup time, ServiceWorker launch time, FetchEventOp propagation through IPC, a FetchEvent creation, initialization, and dispatching/scheduling on worker scope.
Response synthesizing time is the time duration between the fetch handler finishes, which is the resolving/rejecting promise of respondWith(), to the finish of pumping the synthesized response to InterceptedHttpChannel, which is the time point of calling InterceptedHttpChannel::OnStopRequest(). It includes the response propagation through IPC, response header and body synthesis, and pumping synthesized response to the channel.
Interception resetting time is the time duration between the fetch handler finishes and redirecting InterceptedHttpChannel to a normal HTTP channel.
Since the fetch handler is executed on the process where the service worker spawned, the timestamps related to the fetch handler need to be get on that process. So this patch adds the FetchHandlerStart and FetchHandlerFinish on IPCFetchEventRespondWithResult related types to propagate the timestamps to the parent process.
Depends on D118398
Differential Revision: https://phabricator.services.mozilla.com/D118399
Class InterceptionTimeStamps is introduced to help to record fetch-related timing. It is a private class of InterceptedHttpChannel since should use it in InterceptedHttpChannel only.
We are probably not only interested in the resource type, navigation or subresource, but also the final status of fetching, Synthesized, Reset, Canceled, or Redirected. So the fetch's final status also be appended on the sub-key of telemetry.
Depends on D118397
Differential Revision: https://phabricator.services.mozilla.com/D118398
This moves the adding of the end marker for redirects in nsHttpChannel
to SetupReplacementChannel, so that all redirects are properly caught.
Without that, some requests will show as unfinished in the profiler
frontend.
Some of the redirects are internal and we may be able to flag and ignore
them in the frontend, but that's work for the future.
Because all redirections get a "REDIRECT" end marker, including the
internal redirection to the service worker's intercepted channel, we now
need an additional "START" marker there as well.
All existing profiler tests related to service workers needed to be
updated because there's an extra redirect marker in all these requests,
as well as several pairs of markers that all have the same id.
This also adds a new profiler test for handling the http->https case
that we wouldn't catch before this patch.
Differential Revision: https://phabricator.services.mozilla.com/D118836
We enable this mitigation by default because:
- The alternate UX is about:blank or corrupted content. That's never good.
- We want to make sure that our test coverage handles this mitigation because
it's want we want to ship.
However, we do explicitly disable it for all ServiceWorker WPT's via
`__dir__.ini` directive at the root of the service-workers test tree.
This is motivated by the
`/service-workers/service-worker/update-recovery.https.html` test which
intentionally tests a broken ServiceWorker being able to be updated. It
explicitly tests that the intercepted broken iframe shouldn't successfully
load, but our mitigation makes it load, which breaks the test.
Depends on D111845
Differential Revision: https://phabricator.services.mozilla.com/D111993
We enable this mitigation by default because:
- The alternate UX is about:blank or corrupted content. That's never good.
- We want to make sure that our test coverage handles this mitigation because
it's want we want to ship.
However, we do explicitly disable it for all ServiceWorker WPT's via
`__dir__.ini` directive at the root of the service-workers test tree.
This is motivated by the
`/service-workers/service-worker/update-recovery.https.html` test which
intentionally tests a broken ServiceWorker being able to be updated. It
explicitly tests that the intercepted broken iframe shouldn't successfully
load, but our mitigation makes it load, which breaks the test.
Depends on D111845
Differential Revision: https://phabricator.services.mozilla.com/D111993
This moves the adding of the end marker for redirects in nsHttpChannel
to SetupReplacementChannel, so that all redirects are properly caught.
Without that, some requests will show as unfinished in the profiler
frontend.
Some of the redirects are internal and we may be able to flag and ignore
them in the frontend, but that's work for the future.
Because all redirections get a "REDIRECT" end marker, including the
internal redirection to the service worker's intercepted channel, we now
need an additional "START" marker there as well.
All existing profiler tests related to service workers needed to be
updated because there's an extra redirect marker in all these requests,
as well as several pairs of markers that all have the same id.
This also adds a new profiler test for handling the http->https case
that we wouldn't catch before this patch.
Differential Revision: https://phabricator.services.mozilla.com/D118836
When `respondWith` isn't called, then we run the "reset interception"
steps, which sets up a new channel and does an internal redirect. We
need a profiler network marker with the "REDIRECT" status to properly
track this.
Differential Revision: https://phabricator.services.mozilla.com/D112216
