We propergate the isInThirdPartyContext bit from the workerPrivate to
the fetchDrvier. So, we can set the bit for the channel that loads the
fetch request for workers.
Differential Revision: https://phabricator.services.mozilla.com/D207139
WorkerRunnable no longer keeps a raw pointer(mWorkerPrivate) for the associated WorkerPrivate in this patch.
Removing the WorkerRunnable::mWorkerPrivate needs to fix the following problems.
1. Thread assertions in WorkerRunnable::Dispatch()
To fix this problem, the associated WorkerPrivate is as a parameter and passed to WorkerRunnable::Dispatch() for the dispatching thread assertions. This associated WorkerPrivate is also propagated to PreDispatch() and PostDispatch() for the children classes of WorkerRunnable()
2. Get the associated WorkerPrivate in WorkerRunnable::Run() for environment setup(GlobabObject, JSContext setting for the runnable)
- For WorkerThreadRunnable
Since WorkerThreadRunnable is supposed to run on the worker thread, it does not need to keep a raw pointer to WorkerPrivate as its class member. GetCurrentThreadWorkerPrivate() should always get the correct WorkerPrivate for WorkerThreadRunnable.
- For WorkerParentThreadRunnable
WorkerParentRef is introduced to keep a RefPtr<WorkerPrivate> for WorkerParentThreadRunnable instead of using a raw pointer.
Checking the associated WorkerPrivate existence by WorkerParentRef at the beginning of WorkerParentThreadRunnable::Run(). If the Worker has already shut down, WorkerParentThreadRunnable cannot do anything with the associated WorkerPrivate, so WorkerParentThreadRunnable::Run() will return NS_OK directly but with a warning.
The associated WorkerPrivate is also passed into WorkerRun(), PreRun(), and PostRun(), so the majority of implementations of child classes of WorkerRunnable do not need to be changed.
If there are any cases in which the child classes of WorkerThreadRunnable/WorkerParentThreadRunnable want to keep the associated WorkerPrivate, they should use WorkerRefs instead of raw pointers.
Depends on D205679
Differential Revision: https://phabricator.services.mozilla.com/D207039
Sorry for the massive patch but I found it hard to split without
introducing a bunch of copies around...
This mostly makes necko and DOM agree on which strings to use, which
should result on less copies and conversions.
Differential Revision: https://phabricator.services.mozilla.com/D205601
nsIInputStream can exist and then may later go away when the stream becomes unreadable (closed/errored). Since FetchStreamReader is created only when nsIInputStream initially did not exist, the current assertion may fail.
This patch now goes LockStream way if FetchStreamReader doesn't exist, regardless of whether nsIInputStream exists or not.
Differential Revision: https://phabricator.services.mozilla.com/D194413
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
This is a case that Worker is shutting down when WorkerFetchResponseRunnable is in queue.
When Worker is getting into "Canceling" all WorkerRefs are notified, then queued WorkerRunnable are executed.
And this causes PromiseWorkerProxy::mWorkerRef be released before the WorkerRunnable execution.
Before Fx 116, there is no this problem since the queued WorkerFetchResponseRunnable is canceled by WorkerPrivate::ClearMainEventQueue() mechanism.
However, WorkerFetchResponseRunnable needs WorkerRef to keep Worker alive for its WorkerRun execution.
Here we just check if WorkerFetchResolver::mWorkerRef is notified or not to judge if the Worker is in "Canceling." Once the Worker is in "Canceling," return true in WorkerFetchResponseRunnable::WorkerRun directly.
We might need a mechanism for PromiseWorkerProxy to notify the proxy owner worker is shutting down for proxy owner has a way to release resources.
Differential Revision: https://phabricator.services.mozilla.com/D183859
All existing GetBodyStreamHolder call is consciously done on unread streams, either to simply detect nsIInputStream-based streams or to get the internal nsIInputStream. The function can directly return nsIInputStream to fulfill the existing purposes.
Differential Revision: https://phabricator.services.mozilla.com/D178359
This patch is only remove the inheriting, but keeping Cancel() implmentation.
The Cancel() is needed in some special cases, such as Worker enters Canceling when WorkerScope is not created.
Depends on D176915
Differential Revision: https://phabricator.services.mozilla.com/D173850
FetchBody does nothing with the strong reference. Both ReadableStream and FetchStreamReader have their strong references and corresponding cycle collection, so this one can go away.
Depends on D177904
Differential Revision: https://phabricator.services.mozilla.com/D178098
After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor watches channels and NetEvents, stack traces are only caught in the content process.
That means PFetch should notify the netmonitor about the stack trace of the fetch at the proper moment.
In original fetch steps, FetchDriver would notify the netmonitor the fetch stack trace at
https://searchfox.org/mozilla-central/rev/cdddec7fd690700efa4d6b48532cf70155e0386b/dom/fetch/FetchDriver.cpp#834
When PFetch is enabled, PFetch needs also to propagate this notification back to the content process.
Depends on D174442
Differential Revision: https://phabricator.services.mozilla.com/D174443
After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor also watches the channels in the parent process, the created channel still loses the BrowsingContext information for netmonitor to connect the network event and the channel.
This patch is the first part to propagte the worker's associated BrowsingContextID to the parent process through PFetch.
Differential Revision: https://phabricator.services.mozilla.com/D174249
After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor watches channels and NetEvents, stack traces are only caught in the content process.
That means PFetch should notify the netmonitor about the stack trace of the fetch at the proper moment.
In original fetch steps, FetchDriver would notify the netmonitor the fetch stack trace at
https://searchfox.org/mozilla-central/rev/cdddec7fd690700efa4d6b48532cf70155e0386b/dom/fetch/FetchDriver.cpp#834
When PFetch is enabled, PFetch needs also to propagate this notification back to the content process.
Depends on D174442
Differential Revision: https://phabricator.services.mozilla.com/D174443
After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor also watches the channels in the parent process, the created channel still loses the BrowsingContext information for netmonitor to connect the network event and the channel.
This patch is the first part to propagte the worker's associated BrowsingContextID to the parent process through PFetch.
Differential Revision: https://phabricator.services.mozilla.com/D174249
When a network load needs to be intercepted by ServiceWorker, we extract the Request from the InterceptedHttpChannel, and propagate the Request through FetchEvent.request.
However, some needed information is not extracted or is modified during the Request propagation, so getting the wrong result when using the Request to fetch resources in the ServiceWorker script.
Differential Revision: https://phabricator.services.mozilla.com/D145969
Since https://github.com/w3c/FileAPI/issues/43 is still open, it is unclear how body.type should work.
The current wpts expect some behavior which isn't in the specifications.
So, since the situation is very messy in the specifications, the patch is doing a
spot fix for boundary handling. It is ugly, but shouldn't change other behavior.
Differential Revision: https://phabricator.services.mozilla.com/D150018
#include "mozilla/dom/WorkerScope.h" is removed from WorkerPrivate.h, where calling WorkerPrivate::GlobalScope() without include "WorkerScope.h" makes WorkerScope as an incomplete type.
Depends on 132800
Depends on D132800
Differential Revision: https://phabricator.services.mozilla.com/D133483
There are two cases when reading request body by DOM methods:
1. It's being read before fetch()
2. or after fetch()
The first case shouldn't be affected by abort signal per the spec, since the abort step is added only within fetch().
https://fetch.spec.whatwg.org/#ref-for-abortsignal-add
The second case should still fail but with `TypeError: Body has already been consumed`, not AbortError.
Differential Revision: https://phabricator.services.mozilla.com/D136262
