Allow enable() methods to be called manually

[ashbythorpe]

I would like to call Fetch.enable using the patterns and handleAuthRequests arguments. However, since chromote calls Fetch.enable automatically when a callback is attached to a Fetch event, the method is called twice, which causes an error. I would like not to set the auto_events field to FALSE, since I can't change this value after it has been set.

For example:

library(chromote)

session <- ChromoteSession$new()

session$Fetch$enable(
  patterns = list(
    list(urlPattern = "*")
  ),
  handleAuthRequests = TRUE
)

authenticate <- function(x) {
  id <- x$requestId
  
  response <- list(
    response = "ProvideCredentials",
    username = "USERNAME",
    password = "PASSWORD"
  )
  
  session$Fetch$continueWithAuth(
    requestId = id,
    authChallengeResponse = response
  )
}

continue_request <- function(x) {
  id <- x$requestId
  
  session$Fetch$continueRequest(requestId = id)
}

session$Fetch$requestPaused(
  callback_ = continue_request
)

session$Fetch$authRequired(
  callback_ = authenticate
)

session$Page$navigate("https://google.com")

The session$Page$navigate() call causes the following warning:

#> In callbacks$invoke(params) :
#>  1 errors occurred while executing callbacks:
#>  code: -32602
#>  message: Invalid InterceptionId.

It would be useful if either:

• chromote detected when a .enable method is called, and did not call it again when a callback is registered.
• chromote allowed the auto_events field to be modified.

[gadenbuie]

@ashbythorpe Does this still repro for you? I can't reliably trigger the behavior you've described with the example code. Calling session$Page$navigate() doesn't cause the warning described. Maybe there's something missing in the reprex that doesn't fully capture the behavior you saw in your original use case?

[gadenbuie]

I think I have a decent fix in #202 (if you could try it I'd be grateful).

But of course, after going through all of it I've started to wonder if we could just re-order the calls in your reprex so that your call to Fetch$enable() comes after chromote's:

library(chromote)

session <- ChromoteSession$new()

authenticate <- function(x) {
  id <- x$requestId
  
  response <- list(
    response = "ProvideCredentials",
    username = "USERNAME",
    password = "PASSWORD"
  )
  
  session$Fetch$continueWithAuth(
    requestId = id,
    authChallengeResponse = response
  )
}

continue_request <- function(x) {
  id <- x$requestId
  
  session$Fetch$continueRequest(requestId = id)
}

# These two will trigger chromote's auto-events call to `Fetch$enable()`...
session$Fetch$requestPaused(
  callback_ = continue_request
)

session$Fetch$authRequired(
  callback_ = authenticate
)

# ...and maybe this would overwrite chromote's auto enable() call?
session$Fetch$enable(
  patterns = list(
    list(urlPattern = "*")
  ),
  handleAuthRequests = TRUE
)

session$Page$navigate("https://google.com")

[ashbythorpe]

@ashbythorpe Does this still repro for you? I can't reliably trigger the behavior you've described with the example code. Calling session$Page$navigate() doesn't cause the warning described. Maybe there's something missing in the reprex that doesn't fully capture the behavior you saw in your original use case?

I can no longer reproduce the warning, but from my testing, I don't think the handleAuthReqeusts works, and the authenticate() callback is never called, which suggests that the error is still there.

But of course, after going through all of it I've started to wonder if we could just re-order the calls in your reprex so that your call to Fetch$enable() comes after chromote's:

Yes, I tested this, and it works perfectly, of course. I imagine changing the behaviour is still desirable, but up to you.

I've also tested with your PR, and it works as expected.