We need to extract the common method into the idl since the connection between necko
and XHR is idl. Need to import the whole necko if we do something like
`#include "HttpBaseChannel.h"
Differential Revision: https://phabricator.services.mozilla.com/D78830
Initially, IPCInternal{Request,Response} had contained IPCStreams which would
result in unecessary copying when sending the objects over IPC. The patch
makes these streams either:
1) ParentToParentStream (just a UUID)
2) ParentToChildStream (a PIPCBlobInputStream actor, acting as a handle)
3) ChildToParentStream (a real IPCStream)
These three types are union-ed together by the BodyStreamVariant IPDL structure.
This structure replaces the IPCStream members in IPCInternal{Request,Response}
so that, depending on the particular IPDL protocol, we can avoid cloning streams
and just pass handles/IDs instead.
As a side effect, this makes file-backed Response objects cloneable. Initially,
these Responses would be backed by an nsFileInputStream, which is not cloneable
outside the parent process. They are now backed by IPCBlobInputStreams, which
are cloneable.
One thing that's not really satisfactory (IMO), is the manual management of
IPCBlobInputStreamStorage so that no streams are leaked, e.g. if we store a
stream in the IPCBlobInputStreamStorage but fail to send an IPC message and
therefore fail to remove the stream from storage on the other side of the IPC
boundary (only parent-to-parent in this case).
Differential Revision: https://phabricator.services.mozilla.com/D73173
Initially, IPCInternal{Request,Response} had contained IPCStreams which would
result in unecessary copying when sending the objects over IPC. The patch
makes these streams either:
1) ParentToParentStream (just a UUID)
2) ParentToChildStream (a PIPCBlobInputStream actor, acting as a handle)
3) ChildToParentStream (a real IPCStream)
These three types are union-ed together by the BodyStreamVariant IPDL structure.
This structure replaces the IPCStream members in IPCInternal{Request,Response}
so that, depending on the particular IPDL protocol, we can avoid cloning streams
and just pass handles/IDs instead.
As a side effect, this makes file-backed Response objects cloneable. Initially,
these Responses would be backed by an nsFileInputStream, which is not cloneable
outside the parent process. They are now backed by IPCBlobInputStreams, which
are cloneable.
One thing that's not really satisfactory (IMO), is the manual management of
IPCBlobInputStreamStorage so that no streams are leaked, e.g. if we store a
stream in the IPCBlobInputStreamStorage but fail to send an IPC message and
therefore fail to remove the stream from storage on the other side of the IPC
boundary (only parent-to-parent in this case).
Differential Revision: https://phabricator.services.mozilla.com/D73173
Previously we only set some fields as part of WindowGlobalInit, but WindowGlobalParent sets itself as the current window global on the CanonicalBrowsingContext.
This exposes a period of time where only part of the document state was set, and this was observable to consumers.
This makes OnNewDocument only run when there is a new Document for the same WindowGlobal.
Differential Revision: https://phabricator.services.mozilla.com/D75446
Previously we only set some fields as part of WindowGlobalInit, but WindowGlobalParent sets itself as the current window global on the CanonicalBrowsingContext.
This exposes a period of time where only part of the document state was set, and this was observable to consumers.
This makes OnNewDocument only run when there is a new Document for the same WindowGlobal.
Differential Revision: https://phabricator.services.mozilla.com/D75446
Currently, the worker's COEP is saved in WorkerPrivate and not be respected when loading resources in workers.
This patch adds an attribute loadingEmbedderPolicy in nsILoadInfo, which indicates the COEP header the loading must be respected.
The default value of loadingEmbedderPolicy is nsILoadInfo::EMBEDDER_POLICY_NULL.
loadingEmbedderPolicy is initialized with the COEP of the BrowsingContext used for creating LoadInfo.
And it could be set to other value when fetch in workers.
Differential Revision: https://phabricator.services.mozilla.com/D73690
Currently, the worker's COEP value is saved in WorkerPrivate and it is not respected for fetch/cache API in workers.
This patch saving the COEP value which fetch/cache API should be respected when using in workers.
Notice that for the dedicated workers, it is not only respected to worker's COEP but also its owner's.
For fetch in workers, P2 will propagate the COEP value through nsILoadInfo to HttpChannels, such that COEP can be respected in parent process when calling ProcessCrossOriginResourcePolicyHeader() and ProcessCrossOriginEmbedderPolicyHeader().
For cache in workers. We handle it in bug 1603168. COEP will be propagated through CacheRequest to the parent process and respected in CacheOpParent::OnOpComplete().
Differential Revision: https://phabricator.services.mozilla.com/D73689
Initially, IPCInternal{Request,Response} had contained IPCStreams which would
result in unecessary copying when sending the objects over IPC. The patch
makes these streams either:
1) ParentToParentStream (just a UUID)
2) ParentToChildStream (a PIPCBlobInputStream actor, acting as a handle)
3) ChildToParentStream (a real IPCStream)
These three types are union-ed together by the BodyStreamVariant IPDL structure.
This structure replaces the IPCStream members in IPCInternal{Request,Response}
so that, depending on the particular IPDL protocol, we can avoid cloning streams
and just pass handles/IDs instead.
As a side effect, this makes file-backed Response objects cloneable. Initially,
these Responses would be backed by an nsFileInputStream, which is not cloneable
outside the parent process. They are now backed by IPCBlobInputStreams, which
are cloneable.
One thing that's not really satisfactory (IMO), is the manual management of
IPCBlobInputStreamStorage so that no streams are leaked, e.g. if we store a
stream in the IPCBlobInputStreamStorage but fail to send an IPC message and
therefore fail to remove the stream from storage on the other side of the IPC
boundary (only parent-to-parent in this case).
Differential Revision: https://phabricator.services.mozilla.com/D73173
- Worker debugger globals gets a client with a null principal
- Ensure globals are created before script loads
- Introduce WorkerGlobalScopeBase to share code
- Transfer ClientSource ownership from WorkerPrivate to worker globals
- Require getting clients from the globals instead of WorkerPrivate with the
exception of getting the reserved client before the non-debugger global is
created
Differential Revision: https://phabricator.services.mozilla.com/D68936
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
The termination reason doesn't exist in the Fetch spec anymore. The member
variable isn't ever used either.
Differential Revision: https://phabricator.services.mozilla.com/D66539
--HG--
extra : moz-landing-system : lando
Callers should pass in UTF-8, since that's what the JS engine ends up with in the end anyway.
The various URL changes are because NS_NewURI converts incoming nsAString to
UTF-8 anyway. So we might as well do that up-front and then use the UTF-8
string for both the NS_NewURI call and the error-reporting if it fails.
Differential Revision: https://phabricator.services.mozilla.com/D65543
--HG--
extra : moz-landing-system : lando
Given that we are going to add ContentBlockingAllowList in
CookieSettings, so CookieSettings will be responsible for more stuff than the
cookie behavior and cookie permission. We should use a proper name to
reflect the purpose of it. The name 'CookieSettings' is misleading that
this is only for cookie related stuff. So, we decide to rename
'CookieSettins' to 'CookieJarSettings' which serves better meaning here.
Differential Revision: https://phabricator.services.mozilla.com/D63935
--HG--
rename : netwerk/cookie/CookieSettings.cpp => netwerk/cookie/CookieJarSettings.cpp
rename : netwerk/cookie/nsICookieSettings.idl => netwerk/cookie/nsICookieJarSettings.idl
extra : moz-landing-system : lando
This member variable is never used and I can't find the corresponding property
in the Fetch spec.
Differential Revision: https://phabricator.services.mozilla.com/D60077
--HG--
extra : moz-landing-system : lando
This member variable is never used and I can't find the corresponding property
in the Fetch spec.
Differential Revision: https://phabricator.services.mozilla.com/D60076
--HG--
extra : moz-landing-system : lando
Fetch spec says "A request has an associated service-workers mode, that is
"all" or "none". Unless stated otherwise it is "all"." "all" corresponds to
don't skip ServiceWorkers.
Differential Revision: https://phabricator.services.mozilla.com/D60075
--HG--
extra : moz-landing-system : lando
Fetch spec says "A request has an associated response tainting, which is
"basic", "cors", or "opaque". Unless stated otherwise, it is "basic"."
Differential Revision: https://phabricator.services.mozilla.com/D60074
--HG--
extra : moz-landing-system : lando
Fetch spec says "A request has an associated unsafe-request flag. Unless stated otherwise it is unset."
Differential Revision: https://phabricator.services.mozilla.com/D60073
--HG--
extra : moz-landing-system : lando
Fetch spec says "A request has an associated synchronous flag. Unless stated otherwise it is unset.""
Differential Revision: https://phabricator.services.mozilla.com/D60072
--HG--
extra : moz-landing-system : lando
This member variable is never used. It's also not defined by in the Fetch spec
AFAICT. The spec does define a "authentication-fetch flag", but it is not
the property of a request.
Differential Revision: https://phabricator.services.mozilla.com/D60071
--HG--
extra : moz-landing-system : lando
"A request has an associated use-URL-credentials flag. Unless stated otherwise, it is unset."
A quick search shows that this member variable is never actually used. It's
defined by the Fetch spec though, so I didn't delete it in the event that it is
used in the future.
Differential Revision: https://phabricator.services.mozilla.com/D60070
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Honza Bambas
Junior Hsu
Perry Jiang
Brindusan Cristian
Matt Woodrow
Bogdan Tara
Eden Chuang
Christoph Kerschbaumer
Alexandre Poirot
Simon Giesecke
Peter Van der Beken
Csoregi Natalia
Andrea Marchesini
Andreas Farre
Eric Rahm
Mark Banner
Boris Zbarsky
Tim Huang
shindli
Tom Schuster
Edgar Chen