Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
Create a new type of nsHttpAtom, namely nsHttpAtomLiteral. This type is
constexpr-constructible and holds a non-owning reference to its name,
which must have global lifetime.
As a side effect, slightly rework nsHttpAtom interface to replace the
dangerous implicit conversion to const char* by a bool operator and test it.
Differential Revision: https://phabricator.services.mozilla.com/D184557
Create a new type of nsHttpAtom, namely nsHttpAtomLiteral. This type is
constexpr-constructible and holds a non-owning reference to its name,
which must have global lifetime.
As a side effect, slightly rework nsHttpAtom interface to replace the
dangerous implicit conversion to const char* by a bool operator and test it.
Differential Revision: https://phabricator.services.mozilla.com/D184557
This avoids potential issues where multiple OnDataAvailable callbacks or
similar could theoretically be called concurrently on different
StreamTransportService threads when targeting the STS - these cases will
now target a TaskQueue on the STS instead, structurally ensuring serial
execution.
Differential Revision: https://phabricator.services.mozilla.com/D179984
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
