DONTBUILD because just editing an in-tree doc.
This patch fixes a typo by adding a word that was previously missed ("in").
Differential Revision: https://phabricator.services.mozilla.com/D141164
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
And in one case, #include "mozilla/ProfilerThreadState.h" where only `AUTO_PROFILER_THREAD_WAKE` is used.
Depends on D140172
Differential Revision: https://phabricator.services.mozilla.com/D140173
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This will take the place of the existing uses of `aActor->FatalError` in
ipdlc-generated ParamTraits implementations, and will function without an
actor.
Differential Revision: https://phabricator.services.mozilla.com/D140007
This flips around the relationship between IPDLParamTraits and ParamTraits so
that callers can always use ParamTraits instead of IPDLParamTraits.
Differential Revision: https://phabricator.services.mozilla.com/D140005
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 change does not build without the automatically rewritten changes from
part 3c, as every IPC::ParamTraits and IPDLParamTraits implementation needs to
be updated at once, but these are the manual changes which are required and not
handled by the automatic script.
Differential Revision: https://phabricator.services.mozilla.com/D140001
This will allow the types to be more easily automatically substituted in place
of `IPC::Message`, as the type will already be declared in places it is used.
Differential Revision: https://phabricator.services.mozilla.com/D140000
These types will replace `IPC::Message` in ParamTraits method arguments, and
combine the `IPC::Message*`, `PickleIterator` and `IProtocol*` arguments
together into a single argument.
In a future patch this will be used to remove IPDLParamTraits and merge it back
with ParamTraits.
Differential Revision: https://phabricator.services.mozilla.com/D139999
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This is being done because the way the ID is determined causes issue with the
sandbox and the ID is required very early in process start up.
Differential Revision: https://phabricator.services.mozilla.com/D139649
On ARM64 Windows, the GMP process is running in 32-bit, but
the parent process is running in 64-bit. The FlushFOGData reply
sends a ByteBuf from a GMP process to the parent process. This
is a problem because size_t has different sizes in each process.
This patch addresses that by sending the size as a uint32_t.
WriteBytesZeroCopy already implicitly converts the length
argument, so it seems unlikely that the other users of ByteBuf
depend on this behavior. Additionally, I think that any ByteBuf
large enough to cause issues here would end up crashing due to
hitting the IPC message size limit.
Differential Revision: https://phabricator.services.mozilla.com/D139961
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
Releasing ActorLifecycleProxy can lead to the IToplevelProtocol being
destroyed, due to the reference being the last reference. If this happens, we
can deadlock due to the MessageChannel embedded in IToplevelProtocol locking
mMonitor during its' destructor. This patch moves acquiring the proxy earlier
in the method, so that we do not deadlock in this case any longer.
Differential Revision: https://phabricator.services.mozilla.com/D137169
Before this change, OtherPid() would only be initialized for one side of an
actor pair when opening an in-process actor using `IToplevelProtocol::Open` or
`IToplevelProtocol::OpenOnSameThread`. This changes the function to directly
accept the other protocol, and initializes the value correctly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D137168
This is being done because the way the ID is determined causes issue with the
sandbox and the ID is required very early in process start up.
Differential Revision: https://phabricator.services.mozilla.com/D139649
Now that we send everything (except sometimes the user value
is sanitized) we should no longer perform this check.
This is also good because it eliminates security code you
have to have (and thus accidently omitting it is a
vulnerability) and changes it to security code that happens
automatically, and is enforced by the compiler (via mandatory
ctor argument.)
Differential Revision: https://phabricator.services.mozilla.com/D138684
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...
Differential Revision: https://phabricator.services.mozilla.com/D138682
