Chrome stays idle infinitely about chromiumoxide HOT 6 CLOSED

I'm running into the same issue using the exact code here https://github.com/mattsse/chromiumoxide/blob/main/examples/wiki-tokio.rs. My Cargo.toml matches the README. Any updates on this?

chromiumoxide = { git = "https://github.com/mattsse/chromiumoxide", features = ["tokio-runtime"], default-features = false, branch = "main"}

from chromiumoxide.

After some experimentation, based on this problem and solution, it looks like this library cannot handle Chrome using an existing browser session due to a known issue in Chrome. In other words, if you have a Chrome window open already, the Chrome binary that is started by chromiumoxide will use the existing browser session, but it will not know how to bootstrap itself into that browser session because the command does not return the web socket URL.

The workaround (which seems perfectly reasonable to me) is to specify a user data directory which forces Chrome to use create a new browser session:

BrowserConfig::builder().user_data_dir("/tmp").build()

from chromiumoxide.

thanks for digging into this!
I guess there is no easy way to detect this ourself, so we need to make note of this somewhere, maybe add a note in the known issues section?

from chromiumoxide.

Yeah, that seems like a great first step. There are a couple options that I can see

1. We dig into chrome a bit more and see how to get the ws URL for an existing browser session. That would solve the problem, but it means that we run everything within the context of a user's browser; that means user's passwords, user's history, etc. It seems like you'd rarely want to do this, so I feel like this should be explicit behavior.
2. We do something like what chromedp does and create our own temporary user-data-dirs in the system tmp folder every time we run. This guarantees a fresh instance of the browser. https://github.com/chromedp/chromedp/blob/ded6f35d3264c00fcfb622d3e06514fafd82bf46/allocate.go#L142-L151

I personally like option two better, especially since it will be familiar to users of chromedp (and likely puppeteer). I'd be happy to create a PR if that would be helpful.

from chromiumoxide.

seems like option 1 has some drawbacks

option 2 sounds great, even though it requires some temp data.
happy to approve a PR for that :)
I feel like attaching a tempdir handle to the browser config or something could do the trick

from chromiumoxide.

@mattsse I think I took a slightly different approach than what you were going for so feel free to point me in the right direction. I'm fairly new to Rust.

from chromiumoxide.