andrewvy / chrome-launcher Goto Github PK

Each process should log out stderr using its unique identifier by default. Should provide a way to turn this off, but it is nice for debugging.

Chrome needs a fresh new user data dir, so we don't accidentally use a previous existing profile.

See https://chromium.googlesource.com/chromium/src/+/master/docs/user_data_dir.md

Add support for linux chrome installations.

Like in chrome-launcher, https://github.com/GoogleChrome/lighthouse/blob/master/chrome-launcher/chrome-launcher.ts#L252

Before returning the chrome process, poll the process until it's available. Otherwise consumers will try to fire RPC calls before the headless chrome process is ready.

We can use something like gen_tcp to make the initial TCP connection: http://erlang.org/doc/man/gen_tcp.html

thoughts on adding a start_link/1 function that just delegates to launch/1 ?

Migrated from andrewvy/chrome-remote-interface#21

bcardarella:

Because of https://bugs.chromium.org/p/chromium/issues/detail?id=773572&can=1&q=stderr&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

Chrome currently logs everything to stderr. Which means that the current logger is very noisy. I'd like to propose a parser that will determine if Logger.info/2, Logger.warn/2, Logger.debug/2, or Logger.error/2 should be used.

There does seem to be some useful information in the log:

"[1029/202012.957526:WARNING:dns_config_service_posix.cc(336)] Failed to read DnsConfig.\n"

in that example we can see WARNING which leads me to believe we can delegate this message to Logger.warn/2

"[1029/184906.750058:INFO:CONSOLE(25315)]

This could be sent to Logger.info/2 or up for debate. It appears INFO:CONSOLE is anything used for console.log in the browser. Not sure if this should be in the server log.

Instead of polling blindly right when we launch the chrome process with erl-exec, a hacky-way is to wait for stdout before polling.

I think it would be quite helpful to be able to select which chrome I want to run (stable/canary), something like:

{:ok, pid} = ChromeLauncher.launch([remote_debugging_port: 9233, canary: true])

what do you think @andrewvy ?

It would be great ensure the headless chrome instance is torn down properly if the elixir app is terminated.

I've seen intermittent failures to detect that Chrome has launched. In almost all cases I suspect Chrome did launch but not fast enough. The current code appears to have a max timeout of 300ms (10 tries at 30ms each on master)

Looking at the chrome launcher by Google they are also using 10 tries but the delay is 500ms each: https://github.com/GoogleChrome/chrome-launcher/blob/master/chrome-launcher.ts#L119 so the total wait could be up to 5 seconds.

I've tried this size timeout locally and it does appear to clear up any issues I've seen with detecting the process starting.