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
This gets us back to the state we were in with JS Streams. There's a fair
amount of work to get this annotation correct, and some tricky cases to
handle.
Differential Revision: https://phabricator.services.mozilla.com/D136178
This patch makes FetchInstance inherits FetchDriverObserver, such that FatchInstance can resolve the PreloadResponse promise once FetchDriver finishes fetching.
This patch only implements the necessary interface for navigation preload.
OnResponseEnd()
OnResponseAvailableInternal()
Other methods such as NeededOnDataAvailable(), OnDataAvailable is not implemented.
But these methods should be implemented with PFatch implementation.
Depends on D128223
Differential Revision: https://phabricator.services.mozilla.com/D129808
