Bug 1735969: Unify Accessible::TakeFocus, thus allowing it to be used for RemoteAccessibles when the cache is enabled on Windows. r=morgan

1. Add TakeFocus in Windows PDocAccessible.
2. Move RecvTakeFocus into DocAccessibleChildBase so it is used for all platforms.
3. Move TakeFocus into the Accessible base class.
4. Move the IPDL version of TakeFocus into RemoteAccessibleBase so it is used for all plaforms.
5. Make the Windows RemoteAccessible::TakeFocus use the base (IPDL) implementation if the cache is enabled or COM otherwise.
6. Use Accessible::TakeFocus for ATK, Mac, Windows and XPCOM.

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

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

Bug 1540737 originally used PushLayerWithBlend here but PushLayerWithBlend is
not implemented for D2D. Since then, I believe we've stopped using D2D for
content drawing so it should be possible to switch back to PushLayerWithBlend.

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

It's possible for the `PYTHON3` config to point to a different Python
than that that is executing the configure scripts themselves.

This flexibility was needed for the Python 2->3 migration, but now that
it's complete, we can remove the extra configuration and just lean on
the Python interpreter used to run configure.

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

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

Bug 1739298 - Configure RLBox to avoid using locks as it is only used in single threaded contexts r=bholley

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

Bug 1738636 - Return true if the browsing context is not available for a document in AntiTrackingUtils::IsThirdPartyWindow(). r=pbz

The browsing context of a document might be a nullptr in some rare
cases. This patch makes sure we won't pass a null browsingContext to
IsThirdPartyContext() in AntiTrackingUtils::IsThirdPartyWindow().

We don't have a good way to test this. We can only first land the patch
and see if the crash report stops.

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

Backed out 3 changesets (bug 1726617) for causing mda failures on test_peerConnection_setParameters_scaleResolutionDownBy.html. CLOSED TREE

Backed out changeset 6fcd37deab57 (bug 1726617)
Backed out changeset ce2fff273989 (bug 1726617)
Backed out changeset c2b91ea8f0b1 (bug 1726617)

Backed out 7 changesets (bug 1729640) for causing permafailures on browser_web_process_isolation.js. a=backout

Backed out changeset 5b2a1799ce4e (bug 1729640)
Backed out changeset fcd4b833ad73 (bug 1729640)
Backed out changeset 5ff8d3adc6eb (bug 1729640)
Backed out changeset b8fd0343ca42 (bug 1729640)
Backed out changeset fbd6928e34ef (bug 1729640)
Backed out changeset 4ce2eebab0c4 (bug 1729640)
Backed out changeset c7c50c85f911 (bug 1729640)

This exposes synchronous file reading to workers. It's intended to be used
by profiler symbolication.
The API only supports reading into an existing Uint8Array. This avoids
creating garbage, and minimizes copies.
It also keeps the file open so that it doesn't need to be reopened for
each read.

The implementation uses nsFileStream.

I first tried an implementation which used mmap + memcpy rather than read,
but it didn't work for files larger than 2GiB due to limitations in NSPR's
mmap support, and the profiler needs to read >2GiB files.
Specifically, the profiler sometimes needs to read
/System/Library/dyld/dyld_shared_cache_arm64e , which is 2.2GiB big on
macOS 11.5.

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

Bug 1730695 - Fix panic when casting large value to i32 rect r=gfx-reviewers,bradwerth,nical,lsalzman

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

This should unblock removing support for BrokerDuplicateHandle from our fork of
the chromium sandboxing code.

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

Previously this code was using ipc::DuplicateHandle, which was unnecessary, as
the code is being run in the parent process which has access to perform direct
handle transfers. After this patch we'd like to remove ipc::DuplicateHandle and
rely only on attached handles for serialization, so the code is converted to
instead directly use DuplicateHandle.

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

Bug 1732343 - Part 8: Use attached handles for Windows RemoteBackbufferHandles serialization, r=cmartin

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

Bug 1732343 - Part 7: Use attached handles for Windows CrossProcess{Mutex,Semaphore} serialization, r=handyman

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

Bug 1732343 - Part 6: Use attached handles for Windows TransportDescriptor serialization, r=handyman

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

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

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

Handles which are directly attached to IPC messages will be transferred by the
parent process. This is handled either directly by the parent process (if it is
one of the participants), or by relaying the message via the parent process if
it is not. Ordering issues are avoided here thanks to support in the mojo ports
code for messages being delivered out-of-order.

The actual handle values are encoded in the message after the message payload,
and removed from the message before handing it off to existing code, so it
should be fully transparent.

In addition, a new flag is added to the message header to support marking a
message as a "relay" message, as well as support for deserializing these
messages with an extra NodeName (the real target/source) in the message footer.

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

This is useful for the following parts, as UniqueFileHandle is a cross-platform
type which can also be used to support transferring HANDLEs between processes.

This change requires fairly sweeping changes to existing callsites, which
previously did not require owning access to the handle types when transferring.
For the most part these changes were straightforward, but manual.

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

In part 2 of this patch, a large number of messages are being converted to
contain move-only types, both as direct arguments and within compound data
structures. This revealed some limitations in IPDL's handling of moveonly
types, which this patch hopes to rectify. This also required changes to allow
distinguishing between types which require move to send vs. them not having a
move constructor.

This does not fully fix the underlying issues, but attempts to preserve
existing behaviour while improving support for the new types being added. There
should be further cleanup in the future.

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

Bug 1739369 - [marionette] Improve logging for load events in waitForLoadEvent. r=webdriver-reviewers,jdescottes

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

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

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

For now, use IntoIterator to figure the right type to add the bound.

If we need this on types that are iterable but don't provide
IntoIterator, we can add another attribute field or something.

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

This function compiles its string arguments, first creating the top-level
stencil in a way similar to compileToStencil, but then delazify all inner
functions using DelazifyCanonicalScriptedFunction from the previous patch.

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

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

This change clone some of the functions used to initialize the
CompilationSyntaxParseCache. These are specialized to copy the minimal set of
information needed for skipping inner functions and for iterating over
closed-over-bindings.

Unforutnately, as opposed to what this structure was initialy designed for, we
are not yet able to reuse the Stencils from the InputScript as ParseAtomIndex of
the InputScript are in the context of the InputScript and not of the
CompilationState which wraps the CompilationSyntaxParseCache. Until we are
capable of reusing the same indexes of a previous compilation, we would have to
duplicate the Stencil structures. Thus, copyScriptInfo and
copyClosedOVerBindings are copied from the original functions and adapted to
work with Stencil inputs.

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

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

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

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

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

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

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

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

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

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

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

This patchs adds an InputName structure. This structure is used to represent
names held by the GC or another Stencil, and isolate these names such that they
are properly interned before being used in the CompilationState of the existing
compilation.

InputName is a variant over a JSAtom* or a NameStencilRef. The NameStencilRef is
a TaggedParserAtomIndex from a CompilationStencil given as context.

A function is added as part of the ParserAtomsTable, such that
TaggedParserAtomIndex from another compilation can be interned as well. For
encoding where the atom is represented by the tag it-self, this is a no-op,
whereas for larger atoms, these have to be registered in the table. Identically,
another function is added to compare an InputName with an internalized name,
which would be necessary to convert `ScopeContext::searchInEnclosingScope`.

ParserBindingIter are updated to be initialized with a `ScopeStencilRef`, in a
similar way as already done with `Scope*`.

BindingIter and ParserBindingIter creation are wrapped behind the local
InputBindingIter function, used to return one or the other based on the input
type. Identically, InputName can be constructed from a scope and its matching
name type. These would be handy to convert `ScopeContext` methods to
`InputScopeIter`, while maintaining a single implementation of the binding
traversal, which would dispatch to one variant or the other based on the type of
the scope.

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