chromote

chromote copied to clipboard

Hello,

My package giacR starts with this code:

library(chromote)

chrm <- Chrome$new(
  path = find_chrome(),
  args = "--disable-gpu --headless --remote-debugging-port=9222"
)
chromote <- Chromote$new(browser = chrm)
session  <- ChromoteSession$new(parent = chromote)

I have not tried it today but yesterday it worked fine. However, when I run this code today:

chrm <- Chrome$new(
  path = find_chrome(),
  args = "--disable-gpu --headless --remote-debugging-port=9222"
)

then I get the error message

Error in startup(): 
! Chrome debugging port not open after 10 seconds.

Today I set a value to the environment variables HTTP_PROXY and HTTPS_PROXY. Could it be related? My laptop has also been updated (I don't know what have been updated).

Yeah. I confirm this is due to HTTP_PROXY and NO_PROXY. I removed these two variables and it works now. What does that mean?

I found a solution. In my onLoad function, I add:

.onLoad <- function(libname, pkgname) {

  Sys.unsetenv("HTTP_PROXY")

  ........

This works. In this way the HTTP_PROXY variable does not cause any problem.

Now I'm wondering: should I restore this variable at the end of the session? And how?

I'm experiencing this same issue. I have not set HTTP_PROXY or NO_PROXY, and I used Sys.unsetenv() to be sure.

The original package I use that calls Chromote was shinytest2. It was working this morning. But now I'm just directly calling:

library(chromote)
b <- ChromoteSession$new()

And I get the error:

Error in `startup()`:
! Chrome debugging port not open after 10 seconds.

I definitely have Chrome (v118.0.5993.71), which I can launch from an R terminal (system2('cmd', args = '/c start chrome https://www.google.com'), and I'm running on Windows 10 (OS=20348.1970, version=21H2).

Does chromote use chromedriver, like webshot2 does? This sounds like problems updating chromedriver to a version compatible with chrome v118.0.5993.71, which was quite recently released. See https://github.com/ropensci/wdman/issues/34.

I'm not sure if it does (though GPT says it interacts directly with a Chromium-based browser through Chrome DevTools Protocol), but this definitely coincides roughly with the timing of the Chrome update. I installed the beta version of chromedriver (https://googlechromelabs.github.io/chrome-for-testing/#beta) and updated my Windows system PATH to point to it, but I'm still getting the same error. My PATH wasn't pointing to Chromedriver before, either. So maybe chromote uses something else?

I also tried changing the browser to Edge, which is Chromium-based, following the steps here: https://cran.r-project.org/web/packages/chromote/readme/README.html#specifying-which-browser-to-use

1. Sys.setenv(CHROMOTE_CHROME="C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\new_msedge.exe")
2. m <- Chromote$new( browser=Chrome$new(path="C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\new_msedge.exe") )

I think there's a timeout option for Chromote$new, did you try it? 10 seconds is the default value I think.

And did you try the args option?

      chrm <- Chrome$new(
        path = chromePath, # you can use 'find_chrome()'
        args = "--disable-gpu --headless --remote-debugging-port=9222"
      )
      chromote <- Chromote$new(browser = chrm)

I couldn't figure out how to change the default_timeout parameter. I tried your code, but it resulted in the same error after this:

chrm <- Chrome$new(
    path = find_chrome(),
    args = "--disable-gpu --headless --remote-debugging-port=9222"
)

As a reminder, the error is:

Error in `startup()`:
! Chrome debugging port not open after 10 seconds.

I do have a clue: I've been developing and (recently) shinytest2-ing the app in VS Code. However, I'm not encountering the error in R Studio Server. Not sure what to make of that.

Try setting options(chromote.timeout = 60) to timeout after 60, rather than 10, seconds.

That successfully upped the time, but it still didn't work:

Error in `startup()`:
! Chrome debugging port not open after 60 seconds.

What about my answer at the beginning of this thread? Did you try

Sys.unsetenv("HTTP_PROXY")

before dealing with chromote? Do you have an environment variable HTTP_PROXY?

Ah sorry, you already replied... I didn't read.

In case it's helpful, here's the backtrace:

Backtrace:
     ▆
  1. └─ChromoteSession$new()
  2.   └─chromote (local) initialize(...)
  3.     └─chromote::default_chromote_object()
  4.       ├─chromote::set_default_chromote_object(Chromote$new())
  5.       └─Chromote$new()
  6.         └─chromote (local) initialize(...)
  7.           └─Chrome$new()
  8.             └─chromote (local) initialize(...)
  9.               └─chromote:::launch_chrome(path, args)
 10.                 └─chromote:::with_random_port(...)
 11.                   ├─base::tryCatch(...)
 12.                   │ └─base (local) tryCatchList(expr, classes, parentenv, handlers)
 13.                   │   └─base (local) tryCatchOne(expr, names, parentenv, handlers[[1L]])
 14.                   │     └─base (local) doTryCatch(return(expr), name, parentenv, handler)
 15.                   └─chromote (local) startup(port = port, ...)

And here's the specific line that fails: https://github.com/rstudio/chromote/blob/84ac34038639b08cbd166e8cd48c8d9649c0d30d/R/utils.R#L153

Similar to this StackOverflow post, it's working on RStudio Server, but not VS Code or RStudio app, on my VPN.

Does chromote use chromedriver, like webshot2 does? This sounds like problems updating chromedriver to a version compatible with chrome v118.0.5993.71, which was quite recently released. See ropensci/wdman#34.

@dmurdoch I don't think chromote (nor webshot2) use chromedriver. webshot2 uses chromote and AFAIK chromote creates its interface from the protocol spec returned from the running Chrome instance that it tries to connect to.

Similar to this StackOverflow post, it's working on RStudio Server, but not VS Code or RStudio app, on my VPN.

@alex-silverman Can you try looking at the error output of the chrome process on your server? You can use code like the following, I've included the results I see when running chrome locally on my Mac.

library(chromote)

chrm <- Chrome$new(
  path = find_chrome(),
  args = "--disable-gpu --headless"
)

chrm$get_path()
#> [1] "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
chrm$get_port()
#> [1] 7676
readLines(chrm$get_process()$get_error_file())
#> [1] ""
#> [2] "DevTools listening on ws://127.0.0.1:7676/devtools/browser/0b0b64c4-039f-4375-9e74-a11a80e0fd29"

@gadenbuie: Sorry for the noise. I guess it's Rselenium that uses chromedriver.

@gadenbuie - I get the same error/failure on this line:

chrm <- Chrome$new(
  path = find_chrome(),
  args = "--disable-gpu --headless"
)

So I can't even run get_path() or get_port(), etc.

@alex-silverman shoot, sorry, in retrospect it makes sense you wouldn't make it that far. I'm trying to figure out how we can get more logging details out of Chrome. We might not get much, but the error file I read above lives in your R session temp directory. You could try looking at the contents of the log files created in the process of launching (or trying to launch) chrome:

dir(tempdir(), pattern = "chrome-")

Is there anything helpful in there?

woah, I think you might have found the answer! Looks like my admins are blocking it:

DevTools remote debugging is disallowed by the system admin. [1018/131325.610:ERROR:dns_config_service.cc(273)] DNS config watch failed.

Let me check with them to confirm.

Is a solution that retains HTTP_PROXY possible? After debugging, it seems running this function is what causes the error

> url(paste0("http://127.0.0.1:", port, "/json/protocol"), "rb")
Error in url(paste0("http://127.0.0.1:", port, "/json/protocol"), "rb") : 
  cannot open the connection to 'http://127.0.0.1:12007/json/protocol'
In addition: Warning message:
In url(paste0("http://127.0.0.1:", port, "/json/protocol"), "rb") :
  cannot open URL 'http://127.0.0.1:12007/json/protocol': HTTP status was '504 Gateway Timeout'

I've checked with our system admins and they have allowed debugging. If I enter the ip address above in Chrome it also seems to work fine