In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
With this new approach, Shmem instances will now have their handles
transferred inline within messages as attachments, rather than being
associated with their actors and sent in separate messages.
This has a few advantages:
* The implementation is much simpler
* Releasing all references to a Shmem will automatically destroy it by
RAII, rather than leaking the shared memory region until the toplevel
actor is destroyed, removing the need for types like RaiiShmem.
* This allows re-transmitting Shmem instances to another process, as we
don't close the shared memory region handle upon receiving it.
But also has a disadvantage that because we keep alive the shared memory
region's handle until the shmem is destroyed, so that it can be
re-transmitted, we may end up using more FDs or HANDLEs while running.
This patch intentionally doesn't change or simplify callsites, removing
APIs like RaiiShmem, in order to make it easier to revert if this causes
issues on platforms like Linux due to FD exhaustion. If we don't run
into increased resource exhaustion problems, we can make these changes
in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D140211
The Python IPDL frontend checks for includes before checking if the
entire file is syntactically valid. However, my Rust IPDL front end
does it later, so it ends up failing in a syntax error before
noticing the invalid include. I think the basic issue is that this
file wasn't updated when async was made mandatory, because it didn't
affect the results. Let's just fix the file so it only tests one
thing.
Differential Revision: https://phabricator.services.mozilla.com/D141445
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
SimulateDeviceReset() works differently from actual device reset handling. It seems better to make SimulateDeviceReset() more similar to actual device reset handling.
Differential Revision: https://phabricator.services.mozilla.com/D140161
Automatically generated rewrites of all ParamTraits and IPDLParamTraits
implementations in-tree to use IPC::Message{Reader,Writer}.
Differential Revision: https://phabricator.services.mozilla.com/D140004
Updates to the IPDL code generator to make the generated code correctly
use the new ParamTraits APIs for serialization and deserialization.
IPDL continues to use IPDLParamTraits after this change, it will be
changed to use ParamTraits in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D140002
This patch introduces a new system for building IPDL unit tests, which is
roughly inspired by the old cxx unit test design, however designed to work with
gtest. It re-uses the existing IPDLUnitTest process type, using static
constructors only present in xul-gtest to register child actor constructors and
ProcessChild implementations to avoid bloating xul.
The IPDLUnitTest actor is used as a backchannel to communicate test failures
from the child process back to the parent process, and manage the test's async
lifecycle more reliably.
The IPDLUnitTest process also needed to have various properties about how it was
initialized adjusted:
* The IPDLUnitTest process should now always load xul-gtest when running
gtests, by using the "Self" process type and adding a DYLD_LIBRARY_PATH override
on macOS where the "Self" process type cannot be used.
* The IPDLUnitTest process now initializes minimal XPCOM, and runs a
frankeneventloop to allow it to use XPCOM event loop structures such as
SpinEventLoopUntil in tests.
* Support for creating IPDLUnitTest processes on Android was added, as these
tests had never run on android before.
Differential Revision: https://phabricator.services.mozilla.com/D137170
This is a high-level async pipe which can be cheaply transferred between
processes and uses a shared memory ring buffer as its implementation. This can
be used to efficiently stream non-message oriented data between processes and
is not bound to any particular protocol or thread.
Differential Revision: https://phabricator.services.mozilla.com/D135161
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
These attributes replace the previous direct_call.py table which
specified how to locate the concrete implementation of a protocol and
whether it should use a virtual implementation or not.
They work by specifying the concrete type for an actor, and disabling
the automatic inclusion of the implementation's header file, which can
be included explicitly with an `include "";` statement. This allows
customizing both the name and include path of the concrete
implementation of an interface.
Differential Revision: https://phabricator.services.mozilla.com/D137226
This simplifies the logic around descriptors significantly, which is
especially useful considering how few places use the type. There is a
small change required on Windows to create the NamedPipe directly and
transfer around each end's handle, rather than connecting between
processes after the fact.
A named pipe has to be used, rather than an anonymous pipe, as
bidirectional communication is required.
Differential Revision: https://phabricator.services.mozilla.com/D130381
This simplifies the logic around descriptors significantly, which is
especially useful considering how few places use the type. There is a
small change required on Windows to create the NamedPipe directly and
transfer around each end's handle, rather than connecting between
processes after the fact.
A named pipe has to be used, rather than an anonymous pipe, as
bidirectional communication is required.
Differential Revision: https://phabricator.services.mozilla.com/D130381
All uses of the intr message type have been removed from the tree, and the only
remaining uses are in IPDL tests, which currently do not test the IPDL runtime.
This test fully removes support for intr messages from the MessageChannel
interface.
Differential Revision: https://phabricator.services.mozilla.com/D136500
At this point, the only remaining uses of `intr` are in test files. To
avoid the possibility of adding any more (until such time as we deal
with the tests and can get rid of `intr` entirely), this patch requires
a `[LegacyIntr]` attribute on any declaration that uses them, and tags
all the uses in tests with that attribute.
Differential Revision: https://phabricator.services.mozilla.com/D133964
