Bug 1752703 - Move the pthread_thread_create() interposer under mozglue and prepare for having a single place where we place interposer functions r=glandium a=RyanVM

Differential Revision: https://phabricator.services.mozilla.com/D164470

Bug 1826875 - Dispatch using correct thread on UtilityProcessManager missing r=ipc-reviewers,nika a=RyanVM

Differential Revision: https://phabricator.services.mozilla.com/D176618

This patch adds the ability for Windows on ARM to launch either x86 or
ARM Widevine plugins. It also adds the ability for Windows on x86 to
refuse ARM binaries in case, for example, a profile is transferred
between machines.

Overall this should be a non-functional change for users at the time of
landing. It does however allow us to ship the ARM Widevine plugin to
Windows ARM users to workaround a plugin crash with the x86 Widevine
plugin. This only affects Windows 10 users (Windows 11 works fine).

Differential Revision: https://phabricator.services.mozilla.com/D167634

Bug 1790160 - In MessagePumpForUI for Windows, effectively apply upstream's commit 6b9a2fa. r=ipc-reviewers,nika a=RyanVM

As a follow-up to the prior patch, this patch effectively applies upstream's
https://source.chromium.org/chromium/chromium/src/+/6b9a2faf89e9b67fb6cb8d0986c431923f757b98

Differential Revision: https://phabricator.services.mozilla.com/D166521

Bug 1790160 - In MessagePumpForUI for Windows, effectively apply upstream's commit b26918c. r=mossop,ipc-reviewers,gfx-reviewers,nika,nical a=RyanVM

As MessagePumpForUI is an old fork from Chromium, this patch effectively applies
the Chromium patch
https://source.chromium.org/chromium/chromium/src/+/b26918c5ab0da3130b92339f44ebdc4bfee1b351

For those threads where we use MessagePumpForUI we already have a way of
stopping the thread and thereby quitting the message loop. At the same time some
applications may send us unexpected WM_QUIT messages on those threads. Generally
the code using the thread is not able to handle this gracefully and we end up
crashing.

In particular there is a correlation between these crashes and certain antivirus
applications.

Differential Revision: https://phabricator.services.mozilla.com/D166432

Differential Revision: https://phabricator.services.mozilla.com/D153716

Bug 1658869 - Propagate the InterceptedHttpChannel information to fetch's channel casued by FetchEvent.request. r=dom-worker-reviewers,dragana,jesup, a=dmeehan


When a network load needs to be intercepted by ServiceWorker, we extract the Request from the InterceptedHttpChannel, and propagate the Request through FetchEvent.request.

However, some needed information is not extracted or is modified during the Request propagation, so getting the wrong result when using the Request to fetch resources in the ServiceWorker script.

Differential Revision: https://phabricator.services.mozilla.com/D145969

Bug 1789440 - Track reply message IDs for MessageChannel async replies, r=ipc-reviewers,mccr8 a=RyanVM

Differential Revision: https://phabricator.services.mozilla.com/D156569

Bug 1770484 - Make Mac processes not depend on DYLD_LIBRARY_PATH to load libraries r=glandium,gsvelto,mac-reviewers,necko-reviewers,dragana,spohl, a=dmeehan

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

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

Differential Revision: https://phabricator.services.mozilla.com/D150611

Differential Revision: https://phabricator.services.mozilla.com/D147491

Differential Revision: https://phabricator.services.mozilla.com/D145896

Differential Revision: https://phabricator.services.mozilla.com/D145785

Depends on D146501

Differential Revision: https://phabricator.services.mozilla.com/D146502

Bug 1769593 - Part 1: Fail when serializing file handles in excess of MAX_DESCRIPTORS_PER_MESSAGE, r=jld

Differential Revision: https://phabricator.services.mozilla.com/D146501

Differential Revision: https://phabricator.services.mozilla.com/D146964

Before this change, we wouldn't re-try sending fds if the first attempt
to send them failed, meaning that some fds wouldn't arrive if there was
any error sending (e.g. because the send buffer was full, which
is more common on macOS).

This new approach ensures we don't record that we've sent the fds until
the message is marked as successful, and should avoid the macOS errors.

Depends on D145392

Differential Revision: https://phabricator.services.mozilla.com/D146621

This is made possible by part 1, which made it possible to send more messages
using IPC::Channel. A limit is still in place, however it is now substantially
higher, hopefully making it effectively unlimited for practical purposes.

Differential Revision: https://phabricator.services.mozilla.com/D145392

Bug 1767514 - Part 1: Decouple the IPC::Message max handle count and the number of FDs supported by IPC::Channel, r=ipc-reviewers,jld

This is done by splitting messages with large numbers of handles into multiple
`sendmsg` calls, each of which contains less than the maximum number of
transferred handles per-message, and stitching the message back together on the
receiving side. Most of the work on the receiving side was already handled by
the IPC::Channel code, so the work required was only to ensure we could split
the handle list up when sending.

Differential Revision: https://phabricator.services.mozilla.com/D145391

Differential Revision: https://phabricator.services.mozilla.com/D141336

Bug 1768193 - Part 1: Use maybe to hold mIsThirdPartyContextToTopWindow in LoadInfo. r=anti-tracking-reviewers,necko-reviewers,bvandersloot,kershaw

In order to know if the mIsThirdPartyContextToTopWindow was set in the
loadInfo of the channel, we use maybe to hold the value. So, we can know
if it was set before.

This patch also addes two methods in LoadInfo to clear and know if the
value is set.

Differential Revision: https://phabricator.services.mozilla.com/D146491

Differential Revision: https://phabricator.services.mozilla.com/D146930

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

Backed out changeset 9dc2f0c648e4 (bug 1769807) for causing mochitest failures on browser_xpcom_graph_wait.js CLOSED TREE

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

Differential Revision: https://phabricator.services.mozilla.com/D146568

Differential Revision: https://phabricator.services.mozilla.com/D146567

Backed out changeset 0afbb1e34fe3 (bug 1769807) for causing bc failures on browser_xpcom_graph_wait.js. CLOSED TREE

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

Differential Revision: https://phabricator.services.mozilla.com/D146567

Differential Revision: https://phabricator.services.mozilla.com/D146457

Differential Revision: https://phabricator.services.mozilla.com/D146462

Differential Revision: https://phabricator.services.mozilla.com/D145584

Backed out changeset cf237471cf75 (bug 1743020)
Backed out changeset 78eb51447ce5 (bug 1743020)
Backed out changeset c486f95d55ec (bug 1743020)
Backed out changeset c0abfda55404 (bug 1743020)
Backed out changeset 16be18ca73fb (bug 1743020)

Backed out 5 changesets (bug 1769182) for causing mochitest failures on browser_sandbox_test.js. CLOSED TREE

Backed out changeset f5b71a28f28b (bug 1769182)
Backed out changeset 7a64faec004f (bug 1769182)
Backed out changeset c7833370362a (bug 1769182)
Backed out changeset b91adae9bb59 (bug 1769182)
Backed out changeset cf7bb9b7414d (bug 1769182)

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