We want to signal content processes to cancel content JS unconditionally on shutdown.
In the case of parent shutdown this has to happen as early as "quit-application-granted", given that both extensions and session storage shutdown rely on the possibility to interact with content processes (which is not possible when they are inside long running JS).
In addition in the case of a normal child shutdown we cancel content JS execution, too.
For now we put this behind the pref "dom.abort_script_on_child_shutdown" which remains default off.
Depends on D150539
Differential Revision: https://phabricator.services.mozilla.com/D150598
KeyboardShortcut is only supported for XUL menu items.
XUL menu items can never be remote, so there's no point in querying this via IPDL.
Differential Revision: https://phabricator.services.mozilla.com/D151199
KeyboardShortcut is only supported for XUL menu items.
XUL menu items can never be remote, so there's no point in querying this via IPDL.
Differential Revision: https://phabricator.services.mozilla.com/D151199
Mesa 22.1.0 changed the env var name MESA_GLSL_CACHE_DISABLE to
MESA_SHADER_CACHE_DISABLE; it still accepts the old name, but prints a
deprecation warning. If we set both env vars, then we can support both
old and new Mesas correctly (the warning won't be printed if the new env
var is also set).
Differential Revision: https://phabricator.services.mozilla.com/D151094
These changes are partially copied from D148179 (created by jesup). We need to
be able to create correct origin directories from the very beginning.
Differential Revision: https://phabricator.services.mozilla.com/D149259
gcc -std=c++20 (but not clang -std=c++20) complains about template class definitions that specify the template parameter on the class constructor. For example:
template <typename T>
class C {
C(int x) {}
// OK in clang and gcc for both -std=c++17 and -std=c++20.
C<T>(int x, int y) {}
// OK in clang for both -std=c++17 and -std=c++20.
// OK in gcc -std=c++17 but a build error with -std=c++20.
};
The ipc/chromium build error because the `DISALLOW_COPY_AND_ASSIGN` macro expands to such a template class definition:
ipc/chromium/src/base/basictypes.h:53:12: error: expected unqualified-id before 'const'
| TypeName(const TypeName&) = delete
| ^~~~~
ipc/chromium/src/base/threading/thread_local.h:95:3: note: in expansion of macro 'DISALLOW_COPY_AND_ASSIGN'
| DISALLOW_COPY_AND_ASSIGN(ThreadLocalPointer<T>);
| ^~~~~~~~~~~~~~~~~~~~~~~~
Google replaced chromium/base's DISALLOW_COPY_AND_ASSIGN macros with explicitly deleted constructors, so let's apply their upstream fix:
7319bbdb7d
Differential Revision: https://phabricator.services.mozilla.com/D150216
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
There are two parts to this patch; both affect only Linux:
1. The GMP sandbox policy is adjusted to allow certain syscalls used in
shared memory creation (ftruncate and fallocate). However, the file
broker is not used; the process still has no access to files in /dev/shm.
2. The profiler is not initialized for GMP processes unless memfd_create
is available (so the process can create shared memory to send
profiling data back, without filesystem access), or the GMP sandbox
is disabled (either at runtime or build time).
As of this patch, profiling GMP processes on Linux should succeed on
distros with kernel >=3.17 (Oct. 2014), but native stack frames won't
have symbols (and may be incorrectly unwound, not that it matters much
without symbols); see the bug for more info. Pseudo-stack frames and
markers should work, however.
Differential Revision: https://phabricator.services.mozilla.com/D148470
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
