Closed Bug 1543115 Opened 1 year ago Closed 6 months ago

Accomodate to Puppeteer grepping stderr to fetch WebSocket server URL

Categories

(Remote Protocol :: Agent, defect, P1)

defect

Tracking

(firefox72 fixed)

RESOLVED FIXED
Firefox 72
Tracking Status
firefox72 --- fixed

People

(Reporter: ochameau, Assigned: ato)

References

(Blocks 8 open bugs, Regressed 1 open bug)

Details

(Whiteboard: [puppeteer-alpha])

Attachments

(11 files)

2.29 KB, patch
mossop
: feedback+
Details | Diff | Splinter Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review

Puppeteer is grepping the stderr of chromium in order to find the WebSocket server URL that is printed on stderr by chromium in the following form:

$ chromium-browser --remote-debugging-port=9000
DevTools listening on ws://127.0.0.1:9000/devtools/browser/17d40cfd-563c-48c1-aee7-3abbf6d530c1

Here is the code in Puppeteer which does the grepping:
https://github.com/GoogleChrome/puppeteer/blob/2a7c3fe3e68aac3dbca130065a67a8f0aa7db621/lib/Launcher.js#L361

In bug 1539221, I ensured that the WebSocket URL was printed, but there is a couple of things to be done still:

  • Print the message on stderr:
    For now, this is printed on stdout whereas chromium prints that on stderr. Unfortunately I don't know about any JS API to print to stderr.
  • Always print this message:
    For now, this isn't displayed unless you change remote.log.level preference.
  • Change the message to match chromium one:
    We should replace "Remote debugging agent" with "DevTools".

Obviously, we could contribute to Puppeteer to match Firefox behavior, but that wouldn't help supporting Puppeteer old versions.

In the Puppeteer/Juggler sync meeting yesterday, the Puppeteer
developers mentioned that they were changing Puppeteer from scanning
stderr to scanning both stdout + stderr. It doesn’t look like that
has landed yet.

That doesn’t give us compatibility with earlier Puppeteer versions,
but as I understand it this isn’t a concern?

Otherwise I would be happy to write a patch for a new edump()
statement. Alternatively we could use a Rust/C++ component to print
to stderr for us.

Priority: -- → P3

(In reply to Andreas Tolfsen ⦗:ato⦘ from comment #1)

In the Puppeteer/Juggler sync meeting yesterday, the Puppeteer
developers mentioned that they were changing Puppeteer from scanning
stderr to scanning both stdout + stderr. It doesn’t look like that
has landed yet.

It isn't clear when it is going to be changed.
Today's upstream is still using stderr:
https://github.com/GoogleChrome/puppeteer/blob/master/lib/Launcher.js#L327

That doesn’t give us compatibility with earlier Puppeteer versions,
but as I understand it this isn’t a concern?

In the long term, yes, we shouldn't try to be compatible against old Puppeteer versions.

But as we start looking into existing test suites, it is easier to run against
whatever Puppeteer version the test suite is using.
It allows to abstract away failures that may come when upgrading to a more recent version
of Puppeteer. (https://github.com/WordPress/gutenberg/pull/14986)

Also, more concretely, it would allow using an unmodified version of puppeteer to run
against Firefox. For now, I do have to manually patch Launch.js from within node_modules folder.
See bug 1539202 comment 0.

Otherwise I would be happy to write a patch for a new edump()
statement. Alternatively we could use a Rust/C++ component to print
to stderr for us.

If that's easy to implement, it would help testing/running puppeteer in the short term.
(And who knows, it may benefit to other usecases outside of the remote agent?!)

If this is required to run the Puppeteer test suite out of the box,
we need to fix this before we can actually run it in automation.

Assignee: nobody → ato
Status: NEW → ASSIGNED
Priority: P3 → P1

Mossop: This patch introduces a chrome-only edump() global for
writing from JS to stderr. Is something along these lines a thing
we might possibly consider accepting into Gecko?

Attachment #9060962 - Flags: feedback?(dtownsend)
Comment on attachment 9060962 [details] [diff] [review]
0001-edump-proposal.patch

I think this seems like a reasonable thing to add. However I suspect your current fix won't work from JSM files since there are at least 7 different implementations of dump in tree, or at least that is how many I've found so far, each applying to different scopes. This attachment only works from code running in a DOM window.

I'm going back and forwards on whether we should implement edump for all the places that has dump since as mentioned this might be more widely usable, but since I'd prefer we not be logging stuff to the console generally I think just the one change makes more sense.

I think the thing you actually want to alter is this: https://searchfox.org/mozilla-central/source/js/xpconnect/loader/mozJSComponentLoader.cpp#142
Attachment #9060962 - Flags: feedback?(dtownsend) → feedback+

(Though for goodness sake if you felt like writing a patch to unify the multitude of dump implementations I'd be down with that)

An alternative I played around with yesterday, is bootstrapping the
RemoteAgent JS component using Rust. The idea is to implement
nsICommandLineHandler in Rust, because it supports writing to
stderr, and then to call nsIRemoteAgent implemented in JS from
there.

This has the benefit over the edump() patch that it’s work we
would have to do regardless when making the move from httpd.js to
hyper, so there’s potential here for killing two birds with one
stone.

Depends on: 1537768
Depends on: 1551188
Priority: P1 → P2

Marking as P1 so the bug appears in the project's Bugzilla queries.

Priority: P2 → P1

(In reply to Marco Mucci [:MarcoM] from comment #8)

Marking as P1 so the bug appears in the project's Bugzilla queries.

Normally I only mark the thing I’m actually working on as P1.

Thanks for clarifying that. I'll mark it as P2 and available for selection.

Assignee: ato → nobody
Status: ASSIGNED → NEW
Priority: P1 → P2
No longer blocks: 1540655

Another reason not mentioned previously in this bug, and which I
was just painfully reminded of trying to get bug 1540655 landed,
is that dump() only works in debug builds.

That means that for shippable builds, we must even set
browser.dom.window.dump.enabled for the workaround to work!

This is unaccaptable UX and what I would characterise as a show-stopper
for the late-2019 MVP, so I will make it a priority of mine to fix
this as soon as possible.

Assignee: nobody → ato
Status: NEW → ASSIGNED
Priority: P2 → P1
See Also: → 1580470
Blocks: 1589106
Blocks: 1590826
Blocks: 1590827
Blocks: 1590828
Blocks: 1590829
Blocks: 1590830

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.

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().

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.

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.

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.

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

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.

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

This ports the remote agent's implementation of nsICommandLineHandler
from JS to Rust in a way faithful

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.

Whiteboard: [puppeteer-alp
Whiteboard: [puppeteer-alp → [puppeteer-alpha]
Blocks: 1526364
Blocks: 1594760
Blocks: 1594351
No longer blocks: 1594351

Based on a recent try run it appears as if one of the JS changes in this changeset caused a leak:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2d60e3a26630ea6c8db488857f5a8e2b493d616

I will need to resolve this before we can land it.

Blocks: 1595726

I found that nsIRemoteAgent.close() was accessing a null variable
and that this caused us not to clean up the httpd.js instance correctly.

Having plugged the memory leak, I have some confidence in this try run:
https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&tier=1%2C2%2C3&revision=0f6c90016ef5c25345600d07bdcc1951c70a9baf

Pushed by atolfsen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/72c162fff80c
remote: rename XPCOM manifest for conformity; r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/8a931eb7b0c8
remote: merge init() and listen(); r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/76ebc0f74bff
remote: make RemoteAgent.close() safer; r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/4ecb2e70e855
remote: set needed prefs earlier at startup; r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/6480cdbd004c
remote: emit "remote-listening" system notification on startup; r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/825f6b55865a
remote: make RemoteAgent.listen() accept strings; r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/99ae1cdbaa69
remote: introduce nsIRemoteAgent XPIDL interface; r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/0316a7fa9d37
remote: expose nsIRemoteAgent as XPCOM service; r=remote-protocol-reviewers,maja_zf,nika
https://hg.mozilla.org/integration/autoland/rev/df184d5f766a
remote: bootstrap from Rust; r=remote-protocol-reviewers,maja_zf

Backed out 9 changesets (Bug 1543115) for build bustage with fatal error: 'nsIRemoteAgent.h' file not found.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&selectedJob=276969763&resultStatus=testfailed%2Cbusted%2Cexception&searchStr=reftest&revision=df184d5f766ae90887c6e25d267fc56f3046cbfe

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=276973391&repo=autoland&lineNumber=11804

Backout link: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception&searchStr=build&revision=dfb8abe85d3a5265d211365a17f1197cababbf91

[task 2019-11-19T13:48:04.428Z] 13:48:04     INFO -       Running `/builds/worker/workspace/build/src/obj-firefox/release/build/baldrdash-6beb0f8c1cf840cf/build-script-build`
[task 2019-11-19T13:48:04.428Z] 13:48:04     INFO -  [baldrdash 0.1.0] cargo:rerun-if-changed=baldrapi.h
[task 2019-11-19T13:48:04.428Z] 13:48:04     INFO -  [baldrdash 0.1.0] cargo:rerun-if-changed=/builds/worker/workspace/build/src/obj-firefox/js/src/rust/extra-bindgen-flags
[task 2019-11-19T13:48:04.428Z] 13:48:04    ERROR -  error[E0412]: cannot find type `nsIRemoteAgent` in module `interfaces`
[task 2019-11-19T13:48:04.428Z] 13:48:04     INFO -    --> /builds/worker/workspace/build/src/obj-firefox/xpcom/build/services.rs:88:57
[task 2019-11-19T13:48:04.429Z] 13:48:04     INFO -     |
[task 2019-11-19T13:48:04.429Z] 13:48:04     INFO -  88 | pub fn get_RemoteAgent() -> Option<RefPtr<::interfaces::nsIRemoteAgent>> {
[task 2019-11-19T13:48:04.429Z] 13:48:04     INFO -     |                                                         ^^^^^^^^^^^^^^ not found in `interfaces`
[task 2019-11-19T13:48:04.429Z] 13:48:04    ERROR -  error[E0412]: cannot find type `nsIRemoteAgent` in module `interfaces`
[task 2019-11-19T13:48:04.430Z] 13:48:04     INFO -    --> /builds/worker/workspace/build/src/obj-firefox/xpcom/build/services.rs:90:64
[task 2019-11-19T13:48:04.430Z] 13:48:04     INFO -     |
[task 2019-11-19T13:48:04.430Z] 13:48:04     INFO -  90 |         fn XPCOMService_GetRemoteAgent() -> *mut ::interfaces::nsIRemoteAgent;
[task 2019-11-19T13:48:04.430Z] 13:48:04     INFO -     |                                                                ^^^^^^^^^^^^^^ not found in `interfaces`
[task 2019-11-19T13:48:04.430Z] 13:48:04     INFO -  warning: ignoring -C extra-filename flag due to -o flag
[task 2019-11-19T13:48:04.430Z] 13:48:04     INFO -  error: aborting due to 2 previous errors
[task 2019-11-19T13:48:04.430Z] 13:48:04     INFO -  For more information about this error, try `rustc --explain E0412`.
[task 2019-11-19T13:48:04.430Z] 13:48:04    ERROR -  error: Could not compile `xpcom`.
[task 2019-11-19T13:48:04.430Z] 13:48:04     INFO -  Caused by:
[task 2019-11-19T13:48:04.431Z] 13:48:04     INFO -    process didn't exit successfully: `CARGO=/builds/worker/fetches/rustc/bin/cargo CARGO_PKG_VERSION_PRE= CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION=0.1.0 CARGO_PKG_NAME=xpcom CARGO_PKG_VERSION_MINOR=1 CARGO_MANIFEST_DIR=/builds/worker/workspace/build/src/xpcom/rust/xpcom CARGO_PKG_DESCRIPTION= CARGO_PKG_HOMEPAGE= CARGO_PKG_REPOSITORY= CARGO_PKG_AUTHORS='michael@thelayzells.com' LD_LIBRARY_PATH='/builds/worker/workspace/build/src/obj-firefox/release/deps:/builds/worker/fetches/rustc/lib:/builds/worker/fetches/clang/lib' CARGO_PKG_VERSION_PATCH=0 /builds/worker/fetches/sccache/sccache /builds/worker/fetches/rustc/bin/rustc --crate-name xpcom xpcom/rust/xpcom/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C panic=abort -C codegen-units=1 -C metadata=65fb16f0ec428cb6 -C extra-filename=-65fb16f0ec428cb6 --out-dir /builds/worker/workspace/build/src/obj-firefox/thumbv7neon-linux-androideabi/release/deps --target thumbv7neon-linux-androideabi -C linker=/builds/worker/workspace/build/src/build/cargo-linker -L dependency=/builds/worker/workspace/build/src/obj-firefox/thumbv7neon-linux-androideabi/release/deps -L dependency=/builds/worker/workspace/build/src/obj-firefox/release/deps --extern libc=/builds/worker/workspace/build/src/obj-firefox/thumbv7neon-linux-androideabi/release/deps/liblibc-b248775da3bd2a47.rmeta --extern nserror=/builds/worker/workspace/build/src/obj-firefox/thumbv7neon-linux-androideabi/release/deps/libnserror-2c6331789f8edef5.rmeta --extern nsstring=/builds/worker/workspace/build/src/obj-firefox/thumbv7neon-linux-androideabi/release/deps/libnsstring-23111d23a49e1e0e.rmeta --extern thin_vec=/builds/worker/workspace/build/src/obj-firefox/thumbv7neon-linux-androideabi/release/deps/libthin_vec-56af5c06ad6333ba.rmeta --extern threadbound=/builds/worker/workspace/build/src/obj-firefox/thumbv7neon-linux-androideabi/release/deps/libthreadbound-09fb27157990f774.rmeta --extern xpcom_macros=/builds/worker/workspace/build/src/obj-firefox/release/deps/libxpcom_macros-62a7af747cbc18b2.so -C opt-level=2 -C debuginfo=2 -C force-frame-pointers=yes -Dwarnings -C target_feature=+neon,-d16 -Clinker-plugin-lto` (exit code: 1)
[task 2019-11-19T13:48:04.431Z] 13:48:04     INFO -  warning: build failed, waiting for other jobs to finish...
[task 2019-11-19T13:48:04.431Z] 13:48:04     INFO -  [lmdb-rkv-sys 0.9.5] exit code: 0
[task 2019-11-19T13:48:04.432Z] 13:48:04     INFO -  [lmdb-rkv-sys 0.9.5] running: "/builds/worker/fetches/sccache/sccache" "/builds/worker/fetches/clang/bin/clang" "-std=gnu99" "--target=arm-linux-androideabi" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=thumbv7neon-linux-androideabi" "-I/builds/worker/workspace/build/src/obj-firefox/dist/system_wrappers" "-include" "/builds/worker/workspace/build/src/config/gcc_hidden.h" "-fstack-protector-strong" "-DNDEBUG=1" "-DTRIMMED=1" "-I/builds/worker/workspace/build/src/toolkit/library/rust" "-I/builds/worker/workspace/build/src/obj-firefox/toolkit/library/rust" "-I/builds/worker/workspace/build/src/obj-firefox/dist/include" "-I/builds/worker/workspace/build/src/obj-firefox/dist/include/nspr" "-I/builds/worker/workspace/build/src/obj-firefox/dist/include/nss" "-fPIC" "-include" "/builds/worker/workspace/build/src/obj-firefox/mozilla-config.h" "-DMOZILLA_CLIENT" "-Qunused-arguments" "-isystem" "/builds/worker/fetches/android-ndk/sysroot/usr/include/arm-linux-androideabi" "-isystem" "/builds/worker/fetches/android-ndk/sysroot/usr/include" "-gcc-toolchain" "/builds/worker/fetches/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64" "-D__ANDROID_API__=16" "-mno-unaligned-access" "-fno-short-enums" "-fno-exceptions" "-march=armv7-a" "-mthumb" "-mfpu=neon" "-mfloat-abi=softfp" "-fno-strict-aliasing" "-ffunction-sections" "-fdata-sections" "-fno-math-errno" "-fPIC" "-pipe" "-g" "-Xclang" "-load" "-Xclang" "/builds/worker/workspace/build/src/obj-firefox/build/clang-plugin/libclang-plugin.so" "-Xclang" "-add-plugin" "-Xclang" "moz-check" "-Oz" "-fno-omit-frame-pointer" "-funwind-tables" "-DMOZILLA_CONFIG_H" "-DMDB_IDL_LOGN=9" "-o" "/builds/worker/workspace/build/src/obj-firefox/thumbv7neon-linux-androideabi/release/build/lmdb-rkv-sys-cda87b63234fe2a6/out/midl.o" "-c" "/builds/worker/workspace/build/src/third_party/rust/lmdb-rkv-sys/lmdb/libraries/liblmdb/midl.c"
[task 2019-11-19T13:48:04.432Z] 13:48:04     INFO -  [lmdb-rkv-sys 0.9.5] exit code: 0
[task 2019-11-19T13:48:04.432Z] 13:48:04     INFO -  [lmdb-rkv-sys 0.9.5] AR_thumbv7neon-linux-androideabi = None
[task 2019-11-19T13:48:04.432Z] 13:48:04     INFO -  [lmdb-rkv-sys 0.9.5] AR_thumbv7neon_linux_androideabi = Some("/builds/worker/fetches/clang/bin/llvm-ar")
[task 2019-11-19T13:48:04.433Z] 13:48:04     INFO -  [lmdb-rkv-sys 0.9.5] running: "/builds/worker/fetches/clang/bin/llvm-ar" "crs" "/builds/worker/workspace/build/src/obj-firefox/thumbv7neon-linux-androideabi/release/build/lmdb-rkv-sys-cda87b63234fe2a6/out/liblmdb.a" "/builds/worker/workspace/build/src/obj-firefox/thumbv7neon-linux-androideabi/release/build/lmdb-rkv-sys-cda87b63234fe2a6/out/mdb.o" "/builds/worker/workspace/build/src/obj-firefox/thumbv7neon-linux-androideabi/release/build/lmdb-rkv-sys-cda87b63234fe2a6/out/midl.o"
[task 2019-11-19T13:48:04.433Z] 13:48:04     INFO -  [lmdb-rkv-sys 0.9.5] exit code: 0
[task 2019-11-19T13:48:04.433Z] 13:48:04     INFO -  [lmdb-rkv-sys 0.9.5] cargo:rustc-link-lib=static=lmdb
[task 2019-11-19T13:48:04.433Z] 13:48:04     INFO -  [lmdb-rkv-sys 0.9.5] cargo:rustc-link-search=native=/builds/worker/workspace/build/src/obj-firefox/thumbv7neon-linux-androideabi/release/build/lmdb-rkv-sys-cda87b63234fe2a6/out
[task 2019-11-19T13:48:04.433Z] 13:48:04     INFO -  warning: trait objects without an explicit `dyn` are deprecated
[task 2019-11-19T13:48:04.433Z] 13:48:04     INFO -     --> /builds/worker/workspace/build/src/third_party/rust/serde/src/de/mod.rs:200:54
Flags: needinfo?(ato)

It looks like the Rust code is built unconditionally on Android. That shouldn’t happen.

Flags: needinfo?(ato)

I’ve also had to disable the remote agent on Windows AArch64 because
numerous packages depend on winapi 0.2.8 which doesn’t have AArch64
support.

Attachment #9103649 - Attachment description: bug 1543115: remote: bootstrap from Rust; → bug 1543115: remote, toolkit: bootstrap from Rust;

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.

Blocks: 1598286
Pushed by atolfsen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/27f63b79ba66
remote: rename XPCOM manifest for conformity; r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/5deae11d6d8b
remote: merge init() and listen(); r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/87edacb707bd
remote: make RemoteAgent.close() safer; r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/85aaf6349ebb
remote: set needed prefs earlier at startup; r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/eaf3ab5ea7ad
remote: emit "remote-listening" system notification on startup; r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/b52bab54005e
remote: make RemoteAgent.listen() accept strings; r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/7e2f0b7dfe06
remote: introduce nsIRemoteAgent XPIDL interface; r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/27e88dc4bc64
remote: expose nsIRemoteAgent as XPCOM service; r=remote-protocol-reviewers,maja_zf,nika
https://hg.mozilla.org/integration/autoland/rev/836002cd9d1a
remote, toolkit: bootstrap from Rust; r=remote-protocol-reviewers,maja_zf
https://hg.mozilla.org/integration/autoland/rev/ddd503f15330
toolkit: disable remote agent on Windows AArch64; r=froydnj
Blocks: 1600111
You need to log in before you can comment on or make changes to this bug.