Drop the com.apple.security.cs.allow-dyld-environment-variables entitlement to disallow use of dyld environment variables in signed production builds.
Leave the entitlement in for signed developer builds.
Firefox gtests depend on the use of DYLD_LIBRARY_PATH. However, testing infrastructure does not run gtests on signed builds and therefore gtests are not impacted by this change. gtests could be run on signed developer builds in the future which will still allow dyld environment variables after this change.
browser.production.entitlements.xml and plugin-container.production.entitlements.xml are not used, but being kept up to date.
Differential Revision: https://phabricator.services.mozilla.com/D148324
Change XUL and other dylibs to be built with an @rpath/<dylib> install name (LC_ID_DYLIB) instead of @executable_path/<dylib>.
Change executables to be built with an @rpath dyld search path set to @executable_path by default so that @rpath/<dylib> dylibs in the same directory can be resolved. For executables not in the same directory as @rpath dylibs, such as plugin-container, set a relative @rpath such as @executable_path/../../../.
Previously, dylib install names were set as @executable_path/<dylib> allowing them to be resolved by dyld for the loading executable if the executable resided in the same directory as the dylib. For executables not in the same directory as the dylibs, dyld resolved these dylibs using DYLD_LIBRARY_PATH set before launching the process by Firefox code. With this change, loading does not rely on DYLD environment variables. Instead, dylibs have an install name set as @rpath/<dylib> and each executable loading a dylib has its @rpath set at compile-time to refer to dylib directory.
Differential Revision: https://phabricator.services.mozilla.com/D147360
Win32k Lockdown state must be initialized on the main thread, but currently
a process launcher may be the first thing to read it on the IPC Thread
Initializing Win32k Lockdown state also relies on the gfxPlatform being
initialized, but that also isn't explicit anywhere.
This patch ensures both things are true: Always ensure that Win32k State is
initialized before queuing a process launch to the IPC Thread, and always
ensure that gfxPlatform is initialized before attempting to read the
gfx state.
Differential Revision: https://phabricator.services.mozilla.com/D146821
Win32k Lockdown state must be initialized on the main thread, but currently
a process launcher may be the first thing to read it on the IPC Thread
Initializing Win32k Lockdown state also relies on the gfxPlatform being
initialized, but that also isn't explicit anywhere.
This patch ensures both things are true: Always ensure that Win32k State is
initialized before queuing a process launch to the IPC Thread, and always
ensure that gfxPlatform is initialized before attempting to read the
gfx state.
Differential Revision: https://phabricator.services.mozilla.com/D146821
This patch mostly turns on the features set up by the earlier patches:
allow connecting to the X server and reading various related things
(.Xauthority, GPU device info in sysfs, etc.). It also turns off Mesa's
shader cache in the RDD process; that shouldn't be needed here, and
disabling it lets us avoid dealing with a few things in the sandbox
policy that we'd rather not (e.g., `getpwuid`).
Differential Revision: https://phabricator.services.mozilla.com/D146275
Win32k Lockdown state must be initialized on the main thread, but currently
a process launcher may be the first thing to read it on the IPC Thread
Initializing Win32k Lockdown state also relies on the gfxPlatform being
initialized, but that also isn't explicit anywhere.
This patch ensures both things are true: Always ensure that Win32k State is
initialized before queuing a process launch to the IPC Thread, and always
ensure that gfxPlatform is initialized before attempting to read the
gfx state.
Differential Revision: https://phabricator.services.mozilla.com/D146821
This patch mostly turns on the features set up by the earlier patches:
allow connecting to the X server and reading various related things
(.Xauthority, GPU device info in sysfs, etc.). It also turns off Mesa's
shader cache in the RDD process; that shouldn't be needed here, and
disabling it lets us avoid dealing with a few things in the sandbox
policy that we'd rather not (e.g., `getpwuid`).
Differential Revision: https://phabricator.services.mozilla.com/D146275
This makes passing around the type more consistent, and hopefully will make
changes to IPC::Message easier to work with in the future.
In addition, this should save us a few copies as we move the message type into
and out of UniquePtr, however I expect this won't make much of a difference.
Differential Revision: https://phabricator.services.mozilla.com/D145885
This makes passing around the type more consistent, and hopefully will make
changes to IPC::Message easier to work with in the future.
In addition, this should save us a few copies as we move the message type into
and out of UniquePtr, however I expect this won't make much of a difference.
Differential Revision: https://phabricator.services.mozilla.com/D145885
In future parts, TaskQueue will require extra initialization to be performed
which cannot happen in a constructor, as it takes references to the TaskQueue
object itself, which will require the introduction of a helper method. This
patch switches all callers of the TaskQueue constructor to use the new method.
Differential Revision: https://phabricator.services.mozilla.com/D142604
dom/media/ipc/RDDProcessManager.cpp(320,21): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
gpuProcessPid != -1 ? gpuProcessPid : base::GetCurrentProcId();
~~~~~~~~~~~~~ ^ ~~
dom/media/ipc/RDDProcessManager.cpp(332,21): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
if (gpuProcessPid != -1) {
~~~~~~~~~~~~~ ^ ~~
gfx/layers/ipc/SharedSurfacesParent.cpp(360,38): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
if (!gpm || gpm->GPUProcessPid() != -1) {
~~~~~~~~~~~~~~~~~~~~ ^ ~~
ipc/glue/MessageChannel.cpp(2145,13): error: comparison of integers of different signs: 'int32_t' (aka 'int') and 'const base::ProcessId' (aka 'const unsigned long') [-Werror,-Wsign-compare]
if (pid != base::kInvalidProcessId &&
~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~
Differential Revision: https://phabricator.services.mozilla.com/D144688
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
`base::KillProcess`, with the `wait` parameter set to true, does a
bounded blocking wait for the process to exit by polling and sleeping in
a loop, with ad-hoc parameters. The only user of that case is the Gecko
Media Plugin code, which doesn't actually need it as discussed in bug
(comments 4-6); also, currently it's blocking the IPC I/O thread in the
parent process, which is not good for browser responsiveness.
Accordingly, this patch deletes that code and removes the parameter.
Differential Revision: https://phabricator.services.mozilla.com/D136662
We use the process handle returned from `CreateProcess` to derive
another handle with more permissions, but the original handle is never
closed. This bug appears to be fairly old: it existed before this code
was converted to use MozPromise.
Currently we provide the original handle to external consumers of the
launch promise; this patch resolves the promise with the privileged
handle instead and closes the original one. (One consumer uses the
handle only to obtain the pid, and the rest don't use it at all, so this
shouldn't change anything.)
As a related cleanup, `ProcessLaunchPromise` is now exclusive (because
it's resolved with resources which are consumed) and no longer declared
in the header file (because it's used only internally).
Differential Revision: https://phabricator.services.mozilla.com/D119820
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This patch launches content processes with the `MOZ_HEADLESS` env var set
if they're using GTK with an X11 display (and there's no other reason
they'd need GTK).
The goal is to avoid exhausting Xorg's default limit of 256 clients if
there are many content processes due to Fission. If these conditions
are met, the content process doesn't need to eagerly connect to the X
server. This does not affect the sandbox policy, and content processes
can still use X if needed for, e.g., WebGL.
The boolean pref `dom.ipc.avoid-gtk`, set by default, controls this
feature. In the future it could also be extended to minimize GTK use
with Wayland displays.
Note that disabling `widget.non-native-theme.enabled`, which is also
enabled by default, will restore the use of X11 in all content processes
even if this pref is set; the alternative is that widgets wouldn't render
in that case.
This change will also save some memory for now-unnecessary instances of
GTK's global state, and improve content process startup time.
Remove also the temp pref dom.ipc.remote-mozIcon because it cannot work
anymore with the content process being headless.
Differential Revision: https://phabricator.services.mozilla.com/D112197
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This also consumes the existing channel created when launching a process to
create the the conneciton required by NodeController for communicating between
processes. In part 12b, consumers of the broken APIs will be adjusted to use
the new interface.
The new routing approach is not used for the fork server process, as an IO
thread and the NodeController object cannot be initialized before the fork has
been performed, and the IPC requirements of that process are fairly minimal.
Differential Revision: https://phabricator.services.mozilla.com/D112776
This also consumes the existing channel created when launching a process to
create the the conneciton required by NodeController for communicating between
processes. In part 12b, consumers of the broken APIs will be adjusted to use
the new interface.
The new routing approach is not used for the fork server process, as an IO
thread and the NodeController object cannot be initialized before the fork has
been performed, and the IPC requirements of that process are fairly minimal.
Differential Revision: https://phabricator.services.mozilla.com/D112776
