chrlauncher

chrlauncher copied to clipboard

Hi.

puppeteer is an npm library that makes it very easy to automate a browser session. By default, its install includes a complete copy of Chromium. However, it's also able to install without the browser.. and should be able to launch an existing instance of Chromium (or Chrome). Environment variables are used to configure this behavior. For example:

to install:

set PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true
npm install puppeteer --global

to use:

set PUPPETEER_EXECUTABLE_PATH=C:\PortableApps\Chromium\ChromiumPortable.exe
node run_puppeteer_automation_script.js

I've tried using this configuration with:

• PortableApps Google Chrome Portable
• thumbapps Chromium Portable
• chrlauncher

results:

• both PortableApps and thumbapps appear to launch an automated session correctly, but fail to communicate the websocket address to puppeteer, which times out after 30 seconds
• chrlauncher fails immediately

feature request:

• since puppeteer is awesome and widely used..
• since PortableApps launcher is very general purpose..
• since this launcher is tailored specifically to Chromium (and Chrome)..
• it seems like an opportunity for this launcher to fill a niche need..
  if it could find a way to support puppeteer without any additional user configuration

---

edit:

• quickly glancing at the Chrome DevTools Protocol..
  • could it be as simple as piping Chromium's STDERR to the STDERR of the launcher?

more links:

• https://github.com/ChromeDevTools/devtools-protocol
• https://chromedevtools.github.io/devtools-protocol/

---

edit:

John T. Haller at PortableApps addressed this exact issue one year ago.. and said that it wasn't possible (to pipe the STDERR of chrome.exe) using his launcher

---

edit:

code trace...

• in chrlauncher .. where chromium is launched using a method _r_run
• in routine library ..where _r_run method is implemented
• in routine library ..in _r_run method ..where CreateProcess method is called
• an archived copy of an old Microsoft article that illustrates exactly how to call CreateProcess and "redirect the input and output of a child process that receives input from the standard input handle or sends output to the standard output handle".. effectively piping STDIN, STDOUT, and STDERR

---

edit:

cross-referencing the way the PortableApps launcher calls CreateProcess..

• it appears that this NSIS script, written by wraithdu, is where the child process is created
  • unrelated to this feature request, since it's an entirely different project.. but I have to wonder how difficult it would be to modify this script to support redirecting standard i/o

correction:

I was wrong.. after a closer look, it now appears that the default way the PortableApps launcher creates a child process is with the NSIS commands: Exec and ExecWait

• the launcher is also flexible enough to allow this behavior to be customized
  • ..to override the default Execute
• that being said.. the code written by wraithdu may be a clue as to how the child process can be created using a lower-level API in a customized Execute that overrides the default
  • ..which appears to use a thin wrapper around CreateProcess
  • ..I'd test this myself, but I know absolutely nothing about NSIS scripting

in any case:

This brief deep-dive into the PortableApps launcher's code served to prove one thing..

• it would be a lot easier to add this functionality to chrlauncher
  • ..since it's written in C++, rather than NSIS scripts
  • ..since it's already calling CreateProcess, rather than some high-level abstraction that prevents more advanced usage patterns

I think it possible, in near future! Thank you for solution!

Hi @henrypp,

near future calling ;) Any news on this issue?