Romain Lesur

@medewitt Great news! I will resolve the current git conflicts.

Very nice idea! AFAIK, I don't think that this would ensure that `chrome$close()` would be executed at the very end. If I understand well how **promises** work, I think that...

Sorry, I was 100% wrong. I always struggle with `onFinally` (TBH, I dislike it). Here is why. Take this dummy example: ```r library(promises) promise % finally(onFinally = ~ stop("something went...

From the previous example, I think the safest way to use `promises::finally()` in `hold()` would be: ```r promises::then( promises::finally(promise, onFinally = fun), onFulfilled = function(value) { state$pending

I agree: saying that the `timeout` only covers the promise resolution seems more simple.

I wonder whether it could be linked to lazy eval

My guess is it could be related to the use inside `promises::promise()`. I don't have tested so far.

I think we should re-think the model of the `DevToolsConnexion` class. By now, it inherits of the `websocket::WebSocket` class: https://github.com/RLesur/crrri/blob/c873002025b0caf66df895e77617e541d75fccf5/R/DevToolsConnexion.R#L7-L8 With this modelisation, we only can connect to a single...

For this kind of task, I prefer to do the following script, that works: ```r library(crrri) chrome % Network.enable() %>% Network.setRequestInterception(patterns = list(list(urlPattern="*"))) %>% Network.requestIntercepted() %...T>% { print("intercepted") } chrome...

If you want to execute a callback for each intercepted network request, you can use the `.callback` argument ```r library(crrri) chrome % Page.enable() %>% Network.enable() %>% Network.setRequestInterception(patterns = list(list(urlPattern="*"))) %>%...