– DRAFT –
WebDriver-BiDi

<jgraham> RRSAgent: Make minutes v2

<jgraham> RRSAgent: Make logs public

Web Extensions Community Group

jgraham (IRC): this is a FYI item
… I think that this is relevant to this group as there are a lot of similarities between API surface for webextensions and bidi
… e.g. sandbox JS execution

<foolip> Regrets for the meeting happening now, I have other stuff I need to take care of I'm afraid.

AutomatedTester_ (IRC): Is there any documentation this group can read up on?

jgraham (IRC): I don't †hink anything has been released yet... I am mentioning as I think there is potential for collaboration between our group and their group

<brwalder> Charter: https://github.com/w3c/webextensions/blob/main/charter.md

Gecko implementation progress

Design doc: https://docs.google.com/document/d/1Of3ZhWIAwYXPezuG_hMpmTK7Nv1a9_E_VsnBWtD2nD8/edit

jgraham (IRC): The gecko team have sent out an intent to prototype webdriver bidi
… we would love to have feedback on our design document
… we would love to hear from people implementing the client maintainers to make sure this makes sense
… any and all feedback is welcome!

<whimboo> https://groups.google.com/a/mozilla.org/g/dev-platform/c/kASQnIcU9Nc/m/v77WY5siBwAJ

context.navigate

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

jgraham (IRC): the next three items are are status updates and requests for feedback
… foolip (IRC) has reviewed the html parts and hope to get that landed soon
… and this is the last call for the bidi to get this landed soon
… and there has been discussion about how the event ordering should be compared to the command returning
… [gives example around load event]
… this is important to know when a navigation has happened by the test or by something else
… fragments are a special case as they are synchronous
… [describes how things could return]

github-bot (IRC): end topic

<jgraham> github-bot: end topic

context.reload

github-bot (IRC): https://github.com/w3c/webdriver-bidi/issues/107

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

jgraham (IRC): there is a PR for reloading pages
… I think this is largely straight forward
… one feature that is in CDP is force reload
… and HTML spec does not describe what a "force reload is"
… [describes cases that are not obvious]
… all browsers have this so I am assuming this is going to be simple but it could turn out to be not interoperable
… I have noted this in the PR as I think it's important to know but I don't think people are going to change how their browser works

drousso (IRC): I just wanted to mention in safari that a force reload means reload and ignore all the caches

brwalder (IRC): jgraham (IRC) I think you mentioned that force reload is in cdp but I can't see it, I just see ignore cache

jgraham (IRC): I think I assumed they are the same

jgraham (IRC): I can see there cases where "ignore the cache" might not mean what we think it is

whimboo (IRC):are we only allowing this for top level browser context to match browsers

jgraham (IRC): I assumed it was any context and I don't think I have that limitation in the PR
… is "reload a frame" a thing?
… [no replies]

<Honza> Yes, there is "Reload this Frame" action in Firefox

<drousso> that exists in Safari too

<drousso> i think 😅

github-bot: end topic

<drousso> nooooooo the shame 😭

context.traverseHistory

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

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

context.traverseHistory

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

jgraham (IRC): The third change is moving through history
… I have a draft PR for the html spec changes we need
… the model here is that you can move via a delta
… this is different to CDP but the clients do this
… and it is closer to what cypress does as other tools just have back/forward
… and since there are things in the bfcache there might not be events that are returned to the user

github-bot: end topic

Stale Element Reference

github: https://github.com/w3c/webdriver/issues/1594

jgraham (IRC): this is a question that is for all webdriver
… I understand there was a distinction in the past
… the question is what is the expected lifetime...

simonstewart (IRC): The original plan was we kept a cache in the window global.
… if you navigate away and come back it would nuke our cache
… in watir and that they will do a lookup again but selenium doesnt do that and assumes the user knows what is the best wayt to handle this

jgraham (IRC): i think that is good
… I think we need to read the webdriver spec and make sure it does what you have just said
… my inclination is to not have something similar in bidi
… and that in bidi we have more complex objects that are returned
… and they can have large amounts of data that may get stored in a cache

simonstewart (IRC): I think it gets very interested... in webdriver http we required that they keep it instead of the client
… as the browser would know the lifecycles better than a client

jgraham (IRC): my concern is if we return a handle and then it is gc'ed and someone tries to use it and it could return a differrent error

simonstewart (IRC): is this due to JS serialisation

jgraham (IRC): maybe... [discusses]

simonstewart (IRC): in webdriver http we essentially wanted something that could be returned that passed going through `json.stringify`

jgraham (IRC): [discusses JS execution and handles]

simonstewart (IRC): the original plan was due to things that lives in the DOM

jgraham (IRC): that leads to the question about what type of references we need to keep
… one thing that I think is true in http spec but not bidi is...
… if you disconnect an element from the DOM but it's still alive then we would return staleelement reference
… but in JS the handle would still be held
… [missed a few items around usage]

Action: Verify Webdriver HTTP spec matches the requirements and clarify where necessary

github-bot: end topic

Please review the client

github: https://github.com/web-platform-tests/wpt/pull/28381

jgraham (IRC): please review so we can get this landed soon so we can start writing wpt

H2 Priorities

jgraham (IRC): this is part question and statement
… in the spec we are now at a stage to allow parallel spec work
… I am happy to help people get started with that
… and moving forward, the next highest value task is `scriptExecution`
… and there some good easy tasks like screenshots
… and other low hanging fruit
… [describes cases where we need to choose between cdp vs webdriver in this case]

<brwalder> aside: what does "H2" mean here?

<jgraham> jgrahm: Other client priorities seem to be request logging and interception, and user input (could be based on WebDriver actions? Not clear what the requirements are)

automatedtester: what about setting wpt as a priority? and moving to requiring tests for spec changes

jgraham (IRC): yes, I think we can move towards that. We haven't done it yet as there is no client
… and there is no implementation as writing tests in a vacuum is hard

<jgraham> RRSAgent: make minutes v2

<brwalder> Chromium impl prototype: https://github.com/sadym-chromium/bidiInChromeContext

<jgraham> RRSAgent: Make logs public

brwalder (IRC): there is a chromium prototype that sadym (IRC) has been working on
… it's rough but we are starting
… it doesn't do much

<jgraham> RRSAgent: make minutes v2