This reverts commit efd9a5ba48fc380ea38ca827657e6f3fc1a865b5.
Revert "Bug 1968644 - Part 9: Add more tests for loads triggered by tracking scripts. r=valentin,anti-tracking-reviewers,emz"
This reverts commit 7d5c3e1c1ce9e5e41f3054ba7245dda936d14787.
Revert "Bug 1968644 - Part 8: Populate the triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for WebSocket requests. r=valentin,necko-reviewers"
This reverts commit 53a783a51e5e2db3f695150bc85b7af2a34b78a3.
Revert "Bug 1968644 - Part 7: Add tests. r=necko-reviewers,anti-tracking-reviewers,emz,valentin"
This reverts commit e52f034955e34d4c6ad841278894974c615a123f.
Revert "Bug 1968644 - Part 6: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags during channel creation. r=necko-reviewers,kershaw"
This reverts commit f564c21b371c60b240c79a8b56906a9175d58ec3.
Revert "Bug 1968644 - Part 5: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for CSS loads. r=emilio"
This reverts commit 8a8fd7bacc029c91337718e31f7f5911c5afd9a8.
Revert "Bug 1968644 - Part 4: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for loads. r=smaug,necko-reviewers"
This reverts commit 7b3ba3b6689a802718fef2023f9691400611c285.
Revert "Bug 1968644 - Part 3: Populate the triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for fetch requests. r=valentin,smaug"
This reverts commit 08f090244fbab71a14c5e30f740ffcb9cb6f3d31.
Revert "Bug 1968644 - Part 2: Intorduce the ClassificationFlags to nsIClassifiedChannel.idl. r=dimi,necko-reviewers,valentin"
This reverts commit b8c01cd77c4e180b5983dd6a7515b7438676a897.
Revert "Bug 1968644 - Part 1: Introduce triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags to LoadInfo. r=necko-reviewers,kershaw"
This reverts commit a7619a72b4c02e1ff2fa11ce70c954e3313058e1.
We need to propagate the isOn3PCBExceptionList flag from the nsILoadInfo
to workers so that the requests from workers can have the flag to exempt
third-party cookie blocking. We will also tackle the fetch request in
the worker scope in the patch.
Depends on D223380
Differential Revision: https://phabricator.services.mozilla.com/D223936
We need to propagate the isOn3PCBExceptionList flag from the nsILoadInfo
to workers so that the requests from workers can have the flag to exempt
third-party cookie blocking. We will also tackle the fetch request in
the worker scope in the patch.
Depends on D223380
Differential Revision: https://phabricator.services.mozilla.com/D223936
We need to propagate the isOn3PCBExceptionList flag from the nsILoadInfo
to workers so that the requests from workers can have the flag to exempt
third-party cookie blocking. We will also tackle the fetch request in
the worker scope in the patch.
Differential Revision: https://phabricator.services.mozilla.com/D223936
We need to propagate the isOn3PCBExceptionList flag from the nsILoadInfo
to workers so that the requests from workers can have the flag to exempt
third-party cookie blocking. We will also tackle the fetch request in
the worker scope in the patch.
Differential Revision: https://phabricator.services.mozilla.com/D223936
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
