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 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.
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 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
Henri Sivonen
Tom Schuster
Peter Van der Beken
Natalia Csoregi
Jan Varga
Nika Layzell
Emilio Cobos Álvarez
Kagami Sascha Rosylight
Cosmin Sabou
Iulian Moraru
Cristian Tuns
Olli Pettay
Christian Holler
Masayuki Nakano
Noemi Erli
Sebastian Hengst
Butkovits Atila