– DRAFT –
Webdriver March 2021 Meeting

RRSAgent: silence

RRSAgent: set logs public-visible

RRSAgent: create minutes

<jgraham> RRSAgent: Make minutes v2

<jgraham> RRSAgent: Make minutes v2

https://www.w3.org/wiki/WebDriver/2021-03-BiDi

Spec Naming

github: https://github.com/w3c/webdriver-bidi/pull/92

jgraham: The context is that the use of bidi can confuse people from the i18n as they use the term bidi.
… I have an opinion as mentioned in the PR. It's unfortunate that there is overlap but in reality I don't think it's going to block things moving forward
… we could change this to duplex and hope there arent other terms it conflates

foolip: I agree with jgraham here that I don't think expanding will give us much benefit

brwalder: I agree with jgraham and foolip here as it would break continiuty moving forward

<bj> I am also skeptical that changing BiDi to bidirectional is worth the trouble.

jgraham: in half the spec we just use WebDriver-BiDi and for the other half we use the WebDriver-BiDi Protocol we could resolve to always use Protocol in formal contexts

AutomatedTester: it's not like we're conflating it to the extreme like `window` so I don't think we need to do much other than just make it used correrctly elsewherre. It is unfortunate but there is a context here that will always be used so people can be aware.

github: end topic

github-bot: end topic

Navgation progress

github: https://github.com/w3c/webdriver-bidi/issues/43

jgraham: there a comment in https://github.com/w3c/webdriver-bidi/issues/43#issuecomment-795507208
… and I am working on the assumption that we have a way to navigate
… and that we want a way for people to "wait" on certain events or DOM Ready
… there mig
… there might be work on fixing the html spec
… and this for navigations that happen in the client or events that hapepn on the web like links
… fragments are a special case as they are synchronous
… and comparing with CDP, that only shares the lifecycle events
… and we don't need the whole raft of events
… we are likely to know some of the end points of the navigation, like a download, would need to be shared

foolip: there are 2 things like network idle and network almost idle don't appear to be in any spec so we could have that as out of scope

<bj> I strongly prefer to mirror navigation timing and other existing specs.

foolip: we can have this mirror real world specs
… and I think that whimboo said that he exspects people to ask for this striaght away
… and I agree with bj on this that we should follow other specs

brwalder: for clients that want to use network idle as the stopping point
… we would need to intro the concept of a netwrok requests
… which we currently dont have

<foolip> Per https://github.com/puppeteer/puppeteer/blob/main/docs/api.md#pagegotourl-options it looks like "load" is the default of Puppeteer, which is a relief :)

brwalder: any work on network requests would need to be done before we move onto network idle and leave it out of scope for now

<jgraham> It looks like "networkidle2" is a possible value for waitUntil in puppeteer, so not the default but exposed

github-bot: end topic

Using navigable terminology

github: https://github.com/w3c/webdriver-bidi/issues/91

jgraham: in the spec we have the browsing context module
… [describes how this changes in the site isolation case]
… Jake Archibald is improving the html spec around navigable terminology
… so what changes do we want to make?
… we have the browser context id and in webdriver http we use it for navigation
… should we change the concept of browsing context module to a navigable object?

foolip: I just had a quick look at Jakes PR
… could you summarize what this means for us?
… or we can change the name or...

jgraham: I don't know how this works for iframes but I think the relationship is that a browsing context lives within a navigable
… I think this is how it works
… a navigable will own a series of browsing contexts as you traverse history

foolip: and this clarifies that a navigable is not similar to browsing context
… and we need to adapt to be more like html

jgraham: and perhaps my bias is kicking in and I need to double check everything
… I think we can just replace browsing context here with navigable for how we want to use it
… one use case we need to think about is if I return a window handle via executescript should it return a navigable or the window id? how would that work
… I don't think we need to decide now but we need to sort this soon as it will be a backwards breaking change
… so if we can try have an opinion soon

github-bot: end topic

Ownership of serialised objects

github: https://github.com/w3c/webdriver-bidi/issues/90

sadym: in the serialization there is an open question about what do we do when we return an object. in CDP we release objects after a define time
… there is one solution as suggested by jgraham that we keep track of everything until a page navigation is complete
… or have a way for the client to say that the scope is now complete and release all the objects no longer needed

jgraham: I think that is clear thatr we need something like this
… the use case is "return an array containing data that cant be fully serialsed as its too deeply nested" and then it get's GCed and you can't get it
… and I think that we will need to al.low the users to explicitly clean this up especially for single page apps
… we don't want to have a situation where webdriver just creates leaks as it's constantly holding onto life time references
… and it might be good to know what references do we want to hold onto
… do we just need 1 root object or smaller references of what we have accvessed

sadym: my opinion if we expose something to a user we should give them something to allow gc
… if we try save memory by picking something that does by value and some by reference it wont be an economic solution

brwalder: on the subject of holding strong refernce on the root object and not on the nested object
… the main difference between cdp and bidi is that we return a large tree
… so we can just hold the root object
… while in cdp you have to go through the nested object and then assigning a key
… so we can just keep what we have and it should be fine

sadym: that is a good point but there may be a situation where we can't fully serilize and allow users to get the rest

brwalder: I am not sure how that works in cdp
… but in bidi if we keep the strong reference to the object then it woudlnt be gc'ed
… and if we can't fully serialise it in the first tree that the client would be able to get it in a 2nd call
… and we would need to document that in a specific way

jgraham: the disadvantage with a nested object and hold a reference to the root object
… and then it something else comes along and updates it then there will be data missing
… if we create it at a nested model it will be hard for clients to work
… and holding onto the root will be a good first step and easier to implement

sadym: what about a command to explicitly release ?

jgraham: that makes sense and we need to make sure that they are tied to the lifetime of the window object
… the session would have weakref to a realm to a map to a strong reference

foolip: it would be nice if we return an id if we keep a reference and if we dont then ther eis no id
… and cdp does have the concept of object groups

<foolip> CDP releaseObjectGroup is https://chromedevtools.github.io/devtools-protocol/tot/Runtime/#method-releaseObjectGroup

brwalder: I just wanted to addess jgraham 's comment on just holding a strong reference and something modifies it
… I am not convinced it a flaw in the spec and it's a general flaw in JS since that is by ref and not by val
… so it's not really on us to solve this

<jgraham> So a case where this could be a problem is where you e.g. log a js value and later expand it and see the value after it was modified not the value at the time it was logged

bj: object groups in cdp and webinspector are done by injected scripts to a page so they disappear when the page navigates
… so I don't think there much value in adding a system to explicitly clear
… and we've had it working as normal

brwalder: I think bj 's concern is valid

<bj> btw, objectGroup is a parameter to the main evaluateJavaScript command in WebKit's protocol. Which is how console code is able to do anything sensible with it. Other objects are not in a specific object group.

brwalder: if we introduce something like this to bidi we are going to hope users know what to do to do gc
… and since we can return a tree we don't need the idea of object groups because the tree is the object group

<jgraham> RRSAgent: make minutes v2

github-bot: end topic

RRSAgent: make minutes v2