Meeting minutes
Cahir: AutomatedTester
ScibeNick: AutomatedTester
RRSAgent: make logs public
RRSAgent: make minutes v2
<AutomatedTester> https://
RRSAgent: make minutes v2
FPWD
AutomatedTester: Request from W3C to see if we're happy to publish a first working draft. Doesn't affect work, but required for Process reasons, in particular for patent policy.
AutomatedTester: It's about taking a snapshot of where we are and moving forward. Please voice any concerns; there will be a followup email and and issue in the issue tracker. One week for feedback after email/issue. If no objections then we'll go ahead with the FPWD process.
<foolip> Sorry I'm late all, network issues and have joined by phone tether. My audio might be terrible today.
Action: Raise issue for FPWD and send email to list
Review Queue
jgraham: This is a note that there are a few reviews that have been open for awhile. Please can you have a look and help review. There are things that have been reviewed but then there are substantive changes and need to be re-reviewed like `Reload`
foolip: James is being polite, he should be complaining. Would there be appetite for a weekly meeting for editors to help increase the velocity of the PRs
jgraham: I am in agreement. I think having a review/editorial meeting that happens in the middle area between this mmeeting (every 4 weeks starting 2 weeks from now)
<foolip> brwalder has also reviewed a lot
whimboo: Who do we have as editors actively working on reviews
simonstewart: Selenium 4 is nearly shipped and then I will shift focus to the spec
Action: Organise a review meeting every 4 weeks starting from2 weeks from now to bridge the gap between the current webdriver meetings
Shadow DOM
github: https://
jgraham: This is a WebDriver HTTP topic, I noticed in the spec that we are only supporting open shadow DOM. Do we want to support closed shadow DOM?
AutomatedTester: This was a MVP mostly because I don't think we had enough knowledge around closed Shadow dom and there are no obviosu ways to pierce closed shadow doms
simonstewart: I know a lot of people want to pierce closed ones
jgraham: I think that it is true that there are no good ways to handle the closed shadow roots and we need to update the spec accordingly
github: end topic
Script execution
github: https://
jgraham: I have started looking at the spec text here to do the minimum
… I have 3 questions. 2 are in the last comment of the issue linked
… 1. Do we want to keep the distiction between evaluate and callFunctionOn?
… I think we should keep the distinctions
… 2. We want to be able to specify the target of where the script could run. Like the realm or the browser context. There is a question in the PR on what should this look like. It could be a real or a browser context and I have some suggestions there
… 3. How do we want errors to be handled?
… There is a difference between webdriver http and bidi. Webdriver http exxpects the UA to populate it with info
… in CDP it returns a success and then gives you a lot more detailed info
simonstewart: are you saying in CDP you cant tell if there was a success or failing?
jgraham: I've only read the docs but it says that you get a success return but an exception field will be populated
simonstewart: as long as there as a mechanism to differentiate then it's fine since we can do that on the local end
foolip: I want to make sure I understnad the decision. Do we want to return an error at a protocol level or do we just populate a field?
jgraham: The question comes from CDP doing something very different to webdriver. If we want to follow webdriver we would want to have to a mechanism to create more richer error types
… but CDP is there and we can follow that and allow clients to easily move over to it
… and not everything that happens in the client should be returned as a protocol error
<foolip> sadym, do you know off hand what Puppeteer does here? Does it turn script exceptions into a rejected promise?
simonstewart: what ever we do we can always make http sit on top of bidi
… so we want send error types and CDP allows us to send union types
… I don't have a strong opinion here
foolip: If it helps I can move to webdriver http and just do what happens there.
<whimboo> foolip: https://
jgraham: I might look at what existing clients do now and then go from there
<foolip> thanks whimboo!
github: end topic
browsing context create command
github: https://
foolip: THis is a PR that I sent out today
… it's basically boilerplate and some questions
… we should merge jgraham's PRs first and then have a look at this PR
jgraham: There is an open question around creating a context and then do we get events? I think the spec already handles this case already
foolip: I think that's right, we will get the events, it's just around the order of the events.
WebDriver BiDi status in Firefox
whimboo: I just wanted to give a quick update on our implementation
… in the last month, we opened the websocket. users can request the ws url and then connect
… we have started adding commands
… we have added shared session details
… we now have a framework that allows bidi commands and the events
… we have session subscriptions and this will be in Firefox 94
… we have started adding wdspec tests. We have a chicken and egg problem around features vs tests
… we have stumbled into issues with the eventloop
… but this is currently where we are
foolip: Thats really good. Is the "eventloop issues" is that asynchio?
whimboo: yes, we have a fix that will be coming soon. It's ok since it's dropping the eventloop at the end of each module.
<foolip> whimboo, do you have a link to a PR or issue where you've run into this?
jgraham: to answer foolip's question. We should raise this on the wpt repo. We have some things but we should move this to a github disussion
<jgraham> RRSAgent: make minutes v2
<foolip> Thank you, good evening :)
<sadym> thanks!
<jgraham> RRSAgent: make minutes v2