Bugzilla

I’ve taken the original prototype I worked on and ported it to
use the new [BrowsingContext] based [child actor system] that is
now being deployed in the Firefox frontend.  The idea is that this
will be a safer way to structure new code, given that it is its
long-term intention to entirely replace the frame script concept.

The attached prototype is a sparse, but working, implementation
of CDP in Gecko.  Notably, it is missing almost every feature that
CDP has, but provides just enough functionality to make the demo in
remote/test/demo.js work.  The limited feature set is intentional,
as the first order of business should be that we agree on a general
design approach.

A few words of warning when reading the diff:

  - The actor infrastructure has a limitation that child actors have
    to be predefined and registered in the parent process before the
    first child content process starts.  This is a problem since
    the remote agent is essentially an opt-in feature initialised
    with a flag.  Since this is the first Gecko component to need
    on-demand installation of child actors, I don’t believe this
    to be a show-stopper.

  - The transport layer is indisputably terrible, and is held
    together with a piece of string.  We should accept that it is
    necessary to compromise on this to deliver Puppeteer support in
    the short term. But we should be aware that it is a priority to
    move to a high-quality HTTPD based on [rust-cdp] in the longer term.

    As the [rust-cdp] crate provides a complete, typed Rust
    implementation of the CDP protocol, [automatically generated]
    from Chrome’s protocol definition, we could remove entirety
    of the remote/server subfolder and the protocol schema checking
    done in Protocol.jsm.  One of the particularly interesting
    features I find with rust-cdp is that the serde deserialisations
    could be used to delegate to browser-local clients over IPDL,
    meaning this XPCOM remote agent could be just one possible
    underlying implementation.

I’d like to know what you think of this general approach?  I know
there are alternate ways we could approach this (building it in
to devtools’ actor system, but with a CDP-emitting serialiser is
one option), but I feel that the prospect of a modular IPDL/XPCOM
implementation supported by plumbing in rust-cdp holds potential.

[BrowsingContext]: https://searchfox.org/mozilla-central/source/dom/chrome-webidl/BrowsingContext.webidl
[child actor system]: https://searchfox.org/mozilla-central/search?q=ActorManagerParent.jsm
[rust-cdp]: https://github.com/devtools-html/rust-cdp
[automatically generated]: https://groups.google.com/d/msg/mozilla.dev.platform/4-4A8W-nP5g/Y9C9UkWTAAAJ

I’ve taken the original prototype I worked on and ported it to
use the new [BrowsingContext] based [child actor system] that is
now being deployed in the Firefox frontend.  The idea is that this
will be a safer way to structure new code, given that it is its
long-term intention to entirely replace the frame script concept.

The attached prototype is a sparse, but working, implementation
of CDP in Gecko.  Notably, it is missing almost every feature that
CDP has, but provides just enough functionality to make the demo in
remote/test/demo.js work.  The limited feature set is intentional,
as the first order of business should be that we agree on a general
design approach.

A few words of warning when reading the diff:

  - The actor infrastructure has a limitation that child actors have
    to be predefined and registered in the parent process before the
    first child content process starts.  This is a problem since
    the remote agent is essentially an opt-in feature initialised
    with a flag.  Since this is the first Gecko component to need
    on-demand installation of child actors, I don’t believe this
    to be a show-stopper.

  - The transport layer is indisputably terrible, and is held
    together with a piece of string.  We should accept that it is
    necessary to compromise on this to deliver Puppeteer support in
    the short term. But we should be aware that it is a priority to
    move to a high-quality HTTPD based on [rust-cdp] in the longer term.

    As the [rust-cdp] crate provides a complete, typed Rust
    implementation of the CDP protocol, [automatically generated]
    from Chrome’s protocol definition, we could remove entirety
    of the remote/server subfolder and the protocol schema checking
    done in Protocol.jsm.  One of the particularly interesting
    features I find with rust-cdp is that the serde deserialisations
    could be used to delegate to browser-local clients over IPDL,
    meaning this XPCOM remote agent could be just one possible
    underlying implementation.

  - The 17k-dump of the CDP protocol definition in remote/Protocol.jsm
    is pure garbage.  (-;

I’d like to know what you think of this general approach?  I know
there are alternate ways we could approach this (building it in
to devtools’ actor system, but with a CDP-emitting serialiser is
one option), but I feel that the prospect of a modular IPDL/XPCOM
implementation supported by plumbing in rust-cdp holds potential.

[BrowsingContext]: https://searchfox.org/mozilla-central/source/dom/chrome-webidl/BrowsingContext.webidl
[child actor system]: https://searchfox.org/mozilla-central/search?q=ActorManagerParent.jsm
[rust-cdp]: https://github.com/devtools-html/rust-cdp
[automatically generated]: https://groups.google.com/d/msg/mozilla.dev.platform/4-4A8W-nP5g/Y9C9UkWTAAAJ