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.

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

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?

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

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

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

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.

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.

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.

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

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

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

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.

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.

https://hg.mozilla.org/mozilla-central/rev/27f63b79ba66
https://hg.mozilla.org/mozilla-central/rev/5deae11d6d8b
https://hg.mozilla.org/mozilla-central/rev/87edacb707bd
https://hg.mozilla.org/mozilla-central/rev/85aaf6349ebb
https://hg.mozilla.org/mozilla-central/rev/eaf3ab5ea7ad
https://hg.mozilla.org/mozilla-central/rev/b52bab54005e
https://hg.mozilla.org/mozilla-central/rev/7e2f0b7dfe06
https://hg.mozilla.org/mozilla-central/rev/27e88dc4bc64
https://hg.mozilla.org/mozilla-central/rev/836002cd9d1a
https://hg.mozilla.org/mozilla-central/rev/ddd503f15330