The narrative of https://bugzilla.mozilla.org/show_bug.cgi?id=1533831
has changed from shipping the remote agent in Nightly, to turning
it on only for try tests. This will be achieved by first flipping
the remote.enabled preference to false and then implying
--enable-cdp for the default build.

This bug now tracks shipping the remote agent in Nightly, which
code-wise is effectively about reversing the effect of remote.enabled.
This bug is blocked by security review.

We found that this is in fact not a dependency for puppeteer-mvp,
since our fork of the Puppeteer client can ensure to set the
remote.enabled preference in the profile’s user.js file before
starting Firefox.

However, I suspect the security review will be done by the time we
are ready to ship the MVP anyway, and we should plan for that, since
it’s the path of least resistance.

Since we are in nightly now and work with puppeteer client that sets the necessary prefs to get things turned on do we need this bug anymore?

As you say, Puppeteer will work but only because it modifies the profile.
Now that the security review in bug 1542229 and the follow-up work that came out of it is complete,
we should simply go ahead and flip this preference.

I spotted a bug in https://searchfox.org/mozilla-central/source/modules/libpref/init/all.js#4842
where remote.enabled is being installed regardless of whether ENABLE_REMOTE_AGENT is set.

Now that the security review in bug 1542229 and the follow-up work
that came out of it is complete, we should go ahead and flip the
remote.enabled preference.

This patch causes the remote agent to be available to users on the
Firefox Nightly release channel. This meansusing --remote-debugger
will no longer cause a fatal error

https://hg.mozilla.org/mozilla-central/rev/5a69d75cf9b1