feat: support for --remote-debugging-pipe transport

[flotwig]

Closes #381

@cyrus-and I see the conversation in #381 where you expressed that you don't believe pipe support is necessary. IMO, using --remote-debugging-pipe is simpler since you don't need to establish a TCP connection or implement network error handling, so here is a patch that enables a user to pass a process option to use stdio instead of websockets.

Passing process also sets local to true since there may not be a TCP port listening.

Thoughts?

Pre-merge checklist:

• need to add tests - holding off to see if the approach here needs to change. I've manually tested this changeset and it works.
• re-write StdioWrapper to not use puppeteer code?

P.S. this provides some motivation for #439 - since there is no default target when using the stdio transport

[flotwig]

if this is objectionable for some reason, this can be rewritten from scratch, it's not too complicated

[flotwig]

i also considered having the user pass the writeStream and readStream directly, but figured that there is not a use case for it

[cyrus-and]

IMO, using --remote-debugging-pipe is simpler since you don't need to establish a TCP connection or implement network error handling, so here is a patch that enables a user to pass a process option to use stdio instead of websockets.

Yeah, I still don't see why we should need this. The argument that it is simpler is a weak one IMHO since the WebSocket approach is already implemented and well tested, and on the consumer side is just regular exception handling, which BTW you can't never avoid.

What is the real advantage here? The only thing I can think of is that by using the pipe transport you can provide isolation from other users, meaning that only the user that started Chrome can access the CDP, while with the WebSocket approach anyone reaching the endpoint can do that. But this something that can be easily worked around, if really needed, with containerisation.

[flotwig]

What is the real advantage here? The only thing I can think of is that by using the pipe transport you can provide isolation from other users, meaning that only the user that started Chrome can access the CDP, while with the WebSocket approach anyone reaching the endpoint can do that. But this something that can be easily worked around, if really needed, with containerisation.

Well, for one, using stdio lets you isolate CDP without containerization.

It also avoids the need for either (1) detecting the port Chrome chooses with --remote-debugging-port=0 or (2) praying that the random port you chose for --remote-debugging-port is free.

Additionally, I believe Playwright only exposes the CDP implementation in WebKit via stdio, not via port. So this PR is required to use this library with Playwright's patched binaries.

I think stdio transport merits adding, even if you don't think it's the best way to do things, because it's part of CDP as implemented in Chrome. IMO, chrome-remote-interface should support the full extent of CDP's capabilities, including stdio transport.

But if you feel differently, that chrome-remote-interface's goal is not to 100% support CDP in all forms, that's totally your choice. In which case, I'll either just use my fork or use some other library that supports stdio transport, so no worries.

[Kle0s]

Is this PR still alive?

[flotwig]

@Kle0s the changes in this PR work correctly if you'd like to use my fork, but my impression is that @cyrus-and doesn't wish to merge them upstream due to a perceived lack of benefit.

[Kle0s]

@flotwig That's why I also raised another reason to support it - the extension installation in runtime seems to require it according to https://peter.sh/experiments/chromium-command-line-switches/#enable-unsafe-extension-debugging