This combines the multiple fields or variants which were previously used to
track sided types like protocol types into a single field wrapped with a
SideVariant.
This will be used in the next part to avoid the need for default constructors
for actor types allowing the proper types to be used.
Differential Revision: https://phabricator.services.mozilla.com/D168879
While writing part 1 of this patch, I noticed that the geckoview code
for client.openWindow was returning the outer chrome window's
BrowsingContext rather than the BrowsingContext of the primary content
frame when opening a pop-up window. This meant that the native code
would fail to start navigating the pop-up window (as it would try to
navigate the chrome window which is not allowed).
It turns out the tests were still passing because the geckoview code was
actually starting the load itself, though with the wrong options and
properties. In this patch I remove that call to load a URI from the Java
code, and fix the code in ClientOpenWindowUtils to return the content
BrowsingContext instead of the chrome one.
Depends on D171755
Differential Revision: https://phabricator.services.mozilla.com/D171756
This makes various changes to the named lookup/navigation code to make
them more precise, and avoid issues which could happen if a window is
closed while script is still executing.
This also should improve handling for inactive windows in some cases, by
more frequently working off of the WindowContext tree rather than the
BrowsingContext tree.
As part of these changes, some behaviour was changed around e.g. the
file URI exception to avoid the deprecated nsIPrincipal::GetURI method.
I don't believe the behaviour should have changed in a meaningful way.
Differential Revision: https://phabricator.services.mozilla.com/D171755
This introduces a new type to ContentParent which acts as a weak handle to the
actor and is safe to hold and manipulate from any thread.
This replaces accesses of the `ContentParent` type from the background thread,
as they were error-prone due to ContentParent not being threadsafe-refcounted.
The bulk of this patch is piping the new type through to the places it is
required, and removing now-unecessary extra complexity.
Differential Revision: https://phabricator.services.mozilla.com/D162346
This is largely a straightforward find and replace of various methods, with the
unnecessary arguments removed and compiler errors fixed.
Differential Revision: https://phabricator.services.mozilla.com/D148532
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 interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This gives us various positive benefits, such as using a shared memory ring
buffer for faster communication, not having data streaming being bound to the
thread which transferred the nsIInputStream (which is often the main thread),
and the ability for some backpressure to be applied to data streaming.
After this change, the "delayed start" parameter for IPCStream serialization is
less relevant, as backpressure will serve a similar purpose. It will still be
used to determine whether or not to use RemoteLazyInputStream when serializing
from the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D141038
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 interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This gives us various positive benefits, such as using a shared memory ring
buffer for faster communication, not having data streaming being bound to the
thread which transferred the nsIInputStream (which is often the main thread),
and the ability for some backpressure to be applied to data streaming.
After this change, the "delayed start" parameter for IPCStream serialization is
less relevant, as backpressure will serve a similar purpose. It will still be
used to determine whether or not to use RemoteLazyInputStream when serializing
from the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D141038
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 interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This gives us various positive benefits, such as using a shared memory ring
buffer for faster communication, not having data streaming being bound to the
thread which transferred the nsIInputStream (which is often the main thread),
and the ability for some backpressure to be applied to data streaming.
After this change, the "delayed start" parameter for IPCStream serialization is
less relevant, as backpressure will serve a similar purpose. It will still be
used to determine whether or not to use RemoteLazyInputStream when serializing
from the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D141038
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 interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This gives us various positive benefits, such as using a shared memory ring
buffer for faster communication, not having data streaming being bound to the
thread which transferred the nsIInputStream (which is often the main thread),
and the ability for some backpressure to be applied to data streaming.
After this change, the "delayed start" parameter for IPCStream serialization is
less relevant, as backpressure will serve a similar purpose. It will still be
used to determine whether or not to use RemoteLazyInputStream when serializing
from the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D141038
Before this change, the collection of typedefs to include in IPDL
protocols was being performed in the _DecorateWithCXXStuff pass of
lower.py. This pass iterates over all included headers, including
recursively, so will also visit headers included by headers you import.
The recursive behaviour caused issues because importing and
forward-declaring imported types is non-recursive, looking at exported
types only one layer deep. This could lead to typedefs being generated
in IPDL protocols referencing types which could never be named by the
IPDL code, and which had no definition in c++, leading to build errors.
This patch changes the logic to instead happen during the
_GenerateProtocolActorCode pass of lower.py, which is also where
required forward declarations and imports are handled, allowing us to
keep the set of typedefs generated more tightly in sync with the actual
set of types available to the actor.
This required some changes in client code which was relying on
incorrectly generated typedefs, however these types have now been fixed.
Differential Revision: https://phabricator.services.mozilla.com/D141032
This is a mechanical change which was performed by a script based on the
contents of direct_call.py, and then manually checked over to fix
various rewriting bugs caused by my glorified sed script. See the
previous part for more context on the change.
Differential Revision: https://phabricator.services.mozilla.com/D137227
Bug 1723674 added a new nsID::GenerateUUID() static factory function to generate UUIDs without the overhead of querying and instantiating an nsIUUIDGenerator object. nsContentUtils::GenerateUUID() is a utility function that amortizes that overhead by holding an nsIUUIDGenerator singleton. That's no longer necessary because code that calls nsContentUtils::GenerateUUID() can now just call nsID::GenerateUUID(). No nsIUUDGenerator is needed.
Differential Revision: https://phabricator.services.mozilla.com/D132866
#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
ClientValidPrincipalInfo() can be removed from ClientManagerParent::RecvExpect/ForgetFutureSource().
In some redirection cases, ClientChannelHelperParent::CreateClient() will be called in ClientChannelHelper::AsyncOnChannelRedirect(). It would create a new ClientInfo for the new channel's reservedInfo with the new channel's principal, and then propagate the ClientInfo to ClientManagerParent::RecvExpectFutureSource().
https://searchfox.org/mozilla-central/source/dom/clients/manager/ClientChannelHelper.cpp#121,215-216,227,239,251
However, the new channel's principal is not guaranteed to be valid with ClientIsValidPrincipalInfo(). But we don't need to validate it since it could be redirected again. We actually care about is if the principal is valid for the last redirection since we will create an actual ClientSource for it.
We did the checking indirectly in [[ https://searchfox.org/mozilla-central/source/dom/clients/manager/ClientSourceParent.cpp#217,221 | ClientSourceParent::Init() ]]. The ClientInfo used to create ClientSourceParent should be equivalent with used to create FutureClientSourceParent. We also do the ClientInfo equivalence checking [[ https://searchfox.org/mozilla-central/source/dom/clients/manager/ClientManagerService.cpp#254,275-277 | here ]]
So here comes out the conclusion that ClientValidPrincipalInfo() can be removed from ClientManagerParent::RecvExpect/ForgetFutureSource().
Differential Revision: https://phabricator.services.mozilla.com/D134957
#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
Bug 1723674 added a new nsID::GenerateUUID() static factory function to generate UUIDs without the overhead of querying and instantiating an nsIUUIDGenerator object. nsContentUtils::GenerateUUID() is a utility function that amortizes that overhead by holding an nsIUUIDGenerator singleton. That's no longer necessary because code that calls nsContentUtils::GenerateUUID() can now just call nsID::GenerateUUID(). No nsIUUDGenerator is needed.
Differential Revision: https://phabricator.services.mozilla.com/D132866
This patch enables partitioned service workers in third-party contexts.
Doesn't like before, we will allow service workers to be registered even
the third-party contexts don't have storage access and the registered
service workers will be partitioned by the top-level site.
You can control this by using the pref 'privacy.partition.serviceWorkers'.
Setting this to true will enable the partitioning, otherwise, it will
still use the old behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131788
To support foreign partitioned prinicpal for Client, we use
StoragePrincipalHelper::GetPrincipal() to get the foreign partitioned
principal from the channel in the ClientChannelHelper. And use it to
create client.
Differential Revision: https://phabricator.services.mozilla.com/D127631
To support foreign partitioned prinicpal for Client, we use
StoragePrincipalHelper::GetPrincipal() to get the foreign partitioned
principal from the channel in the ClientChannelHelper. And use it to
create client.
Differential Revision: https://phabricator.services.mozilla.com/D127631
