This is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040
This is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040
This is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040
This is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040
We add the new content policy here, but leave the behavior as TYPE_OTHER, so
we can verify that the new test fails before the fix is applied.
Differential Revision: https://phabricator.services.mozilla.com/D124965
As for document.fonts, I don't think we intentionally meant to apply
CSP to User/UserAgent fonts. The document certainly has no authority
to block those from loading. (We already have a separate principal
for these which is further evidence that this was unintentional
and we can use the same bit (mUseOriginPrincipal) to avoid CSP.)
Differential Revision: https://phabricator.services.mozilla.com/D111695
As for document.fonts, I don't think we intentionally meant to apply
CSP to User/UserAgent fonts. The document certainly has no authority
to block those from loading. (We already have a separate principal
for these which is further evidence that this was unintentional
and we can use the same bit (mUseOriginPrincipal) to avoid CSP.)
Differential Revision: https://phabricator.services.mozilla.com/D111695
Stop using `default:` in MapContentPolicyTypeToRequestDestination so that
compilers can notice when people forgot adding a new nsContentPolicyType.
Differential Revision: https://phabricator.services.mozilla.com/D99604
The main point of this change is to not use TYPE_OTHER in `TryCacheLoadAndCompileScript()`,
for extra clarity, we're not using a catch-all TYPE_INTERNAL_SCRIPT.
This is why the changeset introduces a new type TYPE_INTERNAL_FRAME_MESSAGEMANAGER_SCRIPT
which in itself adds lots of changes to various files.
Differential Revision: https://phabricator.services.mozilla.com/D85977
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
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
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
