Meeting minutes
<jgraham> RRSAgent: make logs public
<jgraham> RRSAgent: make minutes v2
<jgraham> RRSAgent: make minutes v2
Serial Max depth
github https://
github: https://
sadym: I was prototyping serialisation a month ago
… and I came across this problem. I have wondered if we want a depth of 1
… jgraham has asked questions before
jgraham: I think the context here is the remote value serialisation
… one thing here is that we are doing things differently to CDP
… in Bidi we serialise everything and return it
… in cdp you have to do more journeys when you have things like arrays
… and we want to optimize for the use case where you are not local to the browser
… and we have cases where there is a large object/array and you only want specific parts of it not the entire thing
… so the question is how do we address this?
… the spec has a depth property so that you can specify what we are doing
… but this can allow people to send too much data... e.g. if it has 2^32-1 properties its a lot to send over the wire
… and there are ways we can solve this
… The main thing is that we want to have a choice that is more choice than what CDP has. We want to have a way to control the verbosity
sadym: There are definite pros for the bidi
… there are times that we need to do the simplest way
… in cdp there are ways that we can use it for the next call and optimizes for that
jgraham: to the idea of using `maxDepth=1` is what makes CDP very chatty
… and if you have N elements in the array you have to do N calls over the wire to populate it
… if there are cases that if you know that know you need we return cases where that we return a small subset of concreate items
… and then for events we have specific serialisation algorithms rather than trying to solve this at a global level
foolip: part of the unstated goal here is that it can be racy when on top of CDP.
… I guess in the future we may need to have this as a goal in CDP in the future
<jgraham> Doesn't this cause a problem for CDP based clients; you're just pushing the race onto them
foolip: I presume this is a problem for them too already. We are not wanting to see cdp change right now but I guess we need to solve that at some point
brwalder: I don't want this to be an implementation chat but I dont think this is a problem in CDP
<foolip> good point, I keep forgetting about that option, brwalder
brwalder: if we keep a weakmap of things then we could probably get around it
sadym: Most of the time in devtools we send back the ids to the devtools
… and that's how we avoid that race condition
jgraham: what's in the spec currently that does serialisation is just events
… and we can have limits for it
… so maxDepth=1 is fine but we will need to revisit this during script execution
github: end topic
github-bot: end topic
Navigation
github: https://
jgraham: This is mostly a status update topic
… the Navigation part of the spec is there that uses Navigable and the events
<drousso> whoops just remembered
<drousso> :P
jgraham: so could people please read the PR
… it resolves relative urls that WebDriver and CDP doesnt do things which I think is nicer for end users
<foolip> I will review, jgraham. Also, I can only join half of the call today, and will leave now.
simonstewart: the reason it's not done in navigate is that I am not clever enough because it's non-trivial
… most users just want to do one navigation and then user interactions to move around the rest of the site
… cb may have more anecdotal data on this
github-bot: end topic
Traversing History
jgraham: the next thing after navigation is traversing the history
… in existing clients there is a page forward/back methods
… however CDP doesnt have what normal clients have. It has the ability to move to specific IDs
… so do we want to standardize on the clients or what on CDP
… I think that CDP is a lot more flexible compared to our clients currently
AutomatedTester: while I think CDP sounds more flexible but in my experience people rarely want to move more than 1 or 2 pages(max) and 2 calls to `back` should be fine
jgraham: I can image a case where the back button could populate the history when clicked and it creates an infinite loop
… so do we want to standardize on what all the clients do it
… or allow more nuanced APIs
… I am in favor of doing what clients do right now as that is the easier option
simonstewart: I support the current clients as it's simplest way
… in the original spec we focused on audiences
… the simpler model works well for testers
… but what about spec authors
jgraham: I think that is valid but it would be good to get the history spec to work in the webdriver way
sadym: I can think of one scenario that needs the complex version but we can add that later if we really need it
Bidi only sessions
github: https://
jgraham: we have been standing up the initial implementation in Gecko
… one of the questions that came up was "should we allow people to start a session without going via HTTP session"
… its for clients that never care about the http commands that webdriver has
… and then there are existing tools like puppeteer/playwright
… from Mozilla we don't really want to ship a http server in Firefox
… or we can rewrite the webdriver http spec to show how this maps across to webdriver bidi
… and I have created a PR on how this could work
… [ describes what is in the PR ]
brwalder: in chromium we ahve a link between webdriver and browser processes that is 1:1. This is done when things are started up and we go from there. I am not against connecting to an existing browser just mentioning it
simonstewart: I don't mind, from selenium, that we connect to a websocket but we need a sessionID so we can make sure that intermediary nodes route things to the right place
drousso: I don't know if we want to expose the websocket because of security/privacy concerns
jgraham: I don't think we want people to have start up the standard browser and there is websocket open as that is a security nightmare
… e.g you would need to tell the browser to start up with a websocket via a driver
… my question is mostly around do we need to do a start a session by calling HTTP POST /SESSION first or connect to a websocket first
… and to brwalder comment I think I have already handled the use case you've mentioned
… [describes a use case for 2 tools running]
… which won't work in the original webdriver because of the blocking commands there
github-bot: end topic
<jgraham> RRSAgent: make minutes v2