Meeting minutes
<jgraham> RRSAgent: make logs public
<jgraham> RRSAgent: make minutes
Remote object lifecycle
<jgraham> github-bot: https://
<github-bot> jgraham, Sorry, I don't understand that command. Try 'help'.
<jgraham> github: https://
<sadym> ะน+
sadym: Splitting implementation into several PRs to keep it easy to review. Currently working on ownership logic and resolving cycles.
foolip: We seem to agree on strong reference to root object. Unclear on whether to allow weak reference to nested objects. What are the use cases for these? Is it more useful for debugging than testing?
<jgraham> brwalder: My last post on the issue was trying to enumerate all the scenarios we might want to support, including cycles and reaching into deeply held objects. Implementation is trending away from persistent object ids. If we decide that reaching into nested objects in subsequent commands isn't important then there are other things we can do that don't have the same memory usage concerns.
<jgraham> ack
simonstewart: If we're trending away from persistent remote object IDs, then how will we compare two objects on the client side? We didn't support this in the original webdriver spec. People came up with expensive workarounds.
sadym: In the current proposal, you would need to provide two IDs and do the equality check on the browser side.
simonstewart: Round trips for object comparision becomes very expensive over the internet and with multiple objects in a large collection.
sadym: What is the scenario for comparing 50+ objects for equality on the client side?
simonstewart: Seeing if a particular element is in a local set. Asserting that two commands return the same object. There is precedent for persistent IDs in the WebDriver spec, i.e. ElementHandles.
sadym: Persistent object IDs is solved for Nodes with sharedId at the moment, but not for general objects.
simonstewart: Goal is to eliminate RPCs whenever possible.
sadym: Motivation for non-persistent IDs: Puppeteer API promises strong references. If we have strong references, there needs to be an explicit API to release the reference. Having persistent strong references seem harder to handle on the client side.
simonstewart: This is the same problem ElementHandles originally had. The solution was to tie the ID to the backend. The reference is invalidated when the page / JS realm goes away.
jgraham: Agreed that for nodes, we should have the same guarantees as classic webdriver. The ID should be persistent across contexts. If you have a need for multiple object comparisons, you can always pass an array of objects to the remote end to do the comparison. Being able to do these comparisons on the client side would be useful but it is difficult to get consensus on this without motivation scenarios.
jgraham: Use the objectId property for serializing cycles in the short term. Consider using this as a persistent ID in the future.
foolip: Nodes and window handles will still have weak references that are useable across calls. Note that there is no current protocol where you can do generic object comparison on the client side. Since no one is currently relying on this, it may not be a priority.
patrickangle_: Seems unnatural for the test client to guarantee lifetime of objects beyond their natural lifetime. Strong references are easier to implement on top of weak references than trying to go the other direction. If every reference is a strong reference, it becomes difficult to reason about subtle lifetime issues.
jgraham: The current spec design requires client to opt in to strong referencing. For compat with existing clients (i.e. Puppeteer), we need at least some way to create strong references.
Network Module
jgraham: Possible compromise. Allow strong reference on root object. If strong ref is not requested, objectIds are used in the serialization for cycles only, not for identification.
<jgraham> GitHub: https://
jgraham: PR draft is up for logging and HAR file scenario. Pretty close to what's in CDP, also considering what extensions do. Please take a look, add comments. Once we have consensus, we can update the Fetch spec and proceed with the PR.
sadym: Took a look and noticed some differences in how redirection is handled vs how CDP handles it. Also some possible issues with cookie handling.
jgraham: Redirect handling may need another look. There is also an issue in the WebDriver spec for cookie and post body encoding. The proposal for cookies follows what WebExtensions does, where there is either a utf8 value field or a binary field.
simonstewart: **Confirmed that this will be the future basis for interception and we won't need to add a new module like CDP.
simonstewart: How are responses handled? Provide by default or opt in? Also how are chunks handled? Do you get multiple events?
jgraham: Not all edge cases are considered yet. These are good questions for the PR.
jgraham: Plan for interception is to add an "isBlocked" field that the client can check and act on. Unclear whether CDPs two separate APIs are a historical accident or a design choice.
"target" property for log.entryAdded events
<jgraham> GitHub: https://
jgraham: Add a context property to the log.entryAdded event to let client know where the log message originated. Should we use the existing target type? Advantage is that if the event comes from a sandbox, you would get the sandbox name too.
<jgraham> [general agreement]
foolip: Do existing protocols support something like this?
<foolip> https://
timeout argument for browsingContext.navigate
<jgraham> github: timeout argument for browsingContext.navigate
<jgraham> github: https://
jgraham: Timeout for navigate. Useful to cancel a navigation that doesn't return immediately. Since we're adding helpers for waiting for DOM loaded events, it seems useful to also cancel that operation if it isn't reached after a certain time.
sadym: What do existing protocols do and what should happen on the browser side if the timeout is reached?
jgraham: Equivalent of the stop button. Or, do what classic WebDriver does.
simonstewart: In classic, if you exceed the global timeout, I think we cancel the request. A primitive to cancel a request would be useful for network interception too. Global timeouts have been limiting in webdriver classic, so having per-command timeouts would be useful.
sadym: Can we make the proposed cancel mechanism part of the network interception API?
<foolip> Looks like https://
jgraham: There's a difference between cancelling a navigation and a network request. A navigation has a 1:N relationship with network requests.
timeout argument for script.evaluate
<jgraham> github https://
<jgraham> github: https://
jgraham: Should script timeout interrupt the script, which may not be possible in every implementation, or just act like a client-side timeout?
simonstewart: Script timeout was originally added because people were running infinite scripts.
This was probably cheaper than attempting to solve the halting problem.
sadym: CDP has no way to interrupt execution.
<jgraham> RRSAgent: make minutes