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

--HG--
extra : moz-landing-system : lando

Backed out changeset 38140fd01a52 (bug 1598259)
Backed out changeset 70b22c90ea2e (bug 1598259)

Backed out changeset 03381ad44ca9 (bug 1547286) to disable Remote Canvas 2D while regressions are investigated and resolved. a=backout

We can't compile the remote agent startup component (written in
Rust) for Windows AArch64 due to numerous packages depending on
winapi 0.2.8 which don't support AArch64.

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

--HG--
extra : moz-landing-system : lando

This bootstraps the remote agent from Rust so that we have access
to write to stderr using the eprintln!() macro.  There is a future
intention to expand Rust usage in the remote agent by delegating
CDP and WebDriver Bi-Di protocol schema validation to serde.

The Rust port is faithful to the JS version in terms of functionality,
and in some places improves on the original design by enforcing
a strict division between flag handling code on one hand, and the
remote agent server on the other.

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

--HG--
extra : moz-landing-system : lando

bug 1543115: remote: expose nsIRemoteAgent as XPCOM service; r=remote-protocol-reviewers,maja_zf,nika

This change makes it possible to access the remote agent service
from C++ and Rust.

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

--HG--
extra : moz-landing-system : lando

Adds an XPIDL interface for the remote agent which we will later use to
initialise and start it from a new command-line handler written in Rust.

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

--HG--
extra : moz-landing-system : lando

Crafting nsIURIs in Rust is complicated.  Allow RemoteAgent.listen()
to accept both strings and nsIURIs when called in JavaScript.

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

--HG--
extra : moz-landing-system : lando

bug 1543115: remote: emit "remote-listening" system notification on startup; r=remote-protocol-reviewers,maja_zf

When calling RemoteAgent.listen() across XPIDL the function is run
asynchronously.  In order to find out when the remote agent has started
listening we introduce a "remote-listening" system observer notification.

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

--HG--
extra : moz-landing-system : lando

Although it currently makes no difference, we should ensure the
required preferences are set sooner, in case any of the internal
remote agent features depend on it.

Because we also cannot control when the nsICommandLineHandler for
the remote agent is invoked, setting it sooner rather than later,
seems a lot safer.

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

--HG--
extra : moz-landing-system : lando

close() is meant to be failsafe in the sense that it should be
possible to call without side-effects.

We are currently setting up a lot of state in listen() that is not
cleaned up if the server eventually fails to start.  Calling close()
when this happens will ensure any state listen() has accrued is reset.

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

--HG--
extra : moz-landing-system : lando

Having init() as a separate function leads to inconsistencies about
how the required state is checked.

init() prevents the remote agent from being loaded when the
remote.enabled preference is false or it is attempted loaded into a
child process, but listen() already manipulates state before these
checks are run.  This is probably not the intention, but an easy
mistake to make when the code flow is not crystal clear.

Since we never have a need to call init() independently, this patch
merges init() into listen().

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

--HG--
extra : moz-landing-system : lando

All other XPCOM component manifests are named components.conf and
this makes the remote agent's conform with those.

It will also become apparent in a later patch in this changeset
that we need to register two XPCOM components: one implementing
the remote agent service, and one for handling command-line arguments.

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

--HG--
rename : remote/RemoteAgent.conf => remote/components.conf
extra : moz-landing-system : lando

--HG--
extra : rebase_source : 0483136a5ea4be8d10938372a7674254a6614af2

This patch adds the following pattern to our x64 detour so that we can hook APIs
even though a target is already detoured by another application.

```
mov   rax, imm64
push  rax
ret
```

We already have `PatchIfTargetIsRecognizedTrampoline` to detour the pattern
`mov; jmp`.  There is another variation using `push rax;ret` to jump.

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

--HG--
extra : moz-landing-system : lando

Backed out changeset afe80b4ff889 (bug 1595934) Requested by ehsan to see if it fixex bug 1597915. On a CLOSED TREE

Backed out 7 changesets (bug 1597216, bug 1596777, bug 1536156) for reftest failures at reftest/bipbop_300_215kbps.mp4.lastframe.htm. On a CLOSED TREE

Backed out changeset a3fa99d936f3 (bug 1536156)
Backed out changeset 29dd64930421 (bug 1536156)
Backed out changeset 77c16444e714 (bug 1536156)
Backed out changeset d540f1802ff6 (bug 1536156)
Backed out changeset 8283eed414d2 (bug 1536156)
Backed out changeset 01d2c84810f0 (bug 1597216)
Backed out changeset e0184916cf37 (bug 1596777)

Bug 1595814 - [marionette] Don't import private _ExpectedFailure and _UnexpectedSuccess classes from unittest. r=whimboo,marionette-reviewers

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

Depends on D53979

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

--HG--
extra : moz-landing-system : lando

Bug 1596479: teach `run-task` to get worker location from `TASKCLUSTER_WORKER_LOCATION` environment var r=tomprince

Previously we inspected the `TASKCLUSTER_WORKER_GROUP` environment variable,
which now only returns the cloud provider of the worker. This commit teaches
`run-task` to instead use the `TASKCLUSTER_WORKER_LOCATION` to gather
information about the location of the worker. We also use the extra data
about the cloud provider for the worker to construct a key for use in the
config, in the form `cloudprovider/region`, so GCP hgweb mirrors can be
amended to the `hgmointernal` config when they are ready.

While we're here we make the error handling for a missing environment
variable slightly nicer.

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

--HG--
extra : moz-landing-system : lando

Switch 'mach test-info report' and 'mach test-info tests' to use the TestManifestLoader.

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

This has the side effect of updating all debian10-based docker images
(except the ones based on debian10-test)

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

Depends on D53775

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

In short - if a user forcibly terminates the browser because it seems
to be permanently hung, we currently do not get a change to record the
hang. This is unfortunate, because these likely represent the most
egregious hangs in terms of user frustration. This patch seeks to
address that.

If a hang exceeds 8192ms (the current definition of a "permahang" in
existing BHR terms), then we decide to immediately persist it to disk,
in case we never get a chance to return to the main thread and
submit it. On the next start of the browser, we read the file from
disk on a background thread, and just submit it using the normal
mechanism.

Regarding the handling of the file itself, I tried to do the simplest
thing I could - as far as I can tell there is no standard simple
serialization mechanism available directly to C++ in Gecko, so I just
serialized it by hand. I didn't take any special care with endianness
or anything as I can't think of a situation in which we really care
at all about these files being transferable between architectures. I
directly used PR_Write / PR_Read instead of doing something fancy
like memory mapping the file, because I don't think performance is a
critical concern here and it offers a simple protection against
reading out of bounds.

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

--HG--
extra : moz-landing-system : lando

Bug 1572627 implement currentFrame, currentTime, and sampleRate members on AudioWorkletGlobalScope r=padenot

Depends on D54084

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

--HG--
extra : moz-landing-system : lando

Bug 1572627 expose ProcessedTime() as a graph-global time updated after processing all tracks r=padenot

This is similar to [[current frame]] in Web Audio, but is in GraphTime,
not AudioContext-specific time.

Depends on D54083

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

so that mProcessedTime can be updated for each block processed.

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

--HG--
extra : moz-landing-system : lando