15:59:35 <RRSAgent> RRSAgent has joined #webdriver
15:59:35 <RRSAgent> logging to https://www.w3.org/2020/10/26-webdriver-irc
15:59:43 <AutomatedTester> RRSAgent: quiet
15:59:43 <RRSAgent> I'm logging. I don't understand 'quiet', AutomatedTester.  Try /msg RRSAgent help
16:00:10 <AutomatedTester> RRSAgent silence
16:00:48 <Zakim> Zakim has joined #webdriver
16:03:01 <AutomatedTester> gsnedders: hey :) what's the github bot name?
16:04:29 <AutomatedTester> RRSAgent: listen
16:05:11 <AutomatedTester> Meeting: WebDriver WG @ TPAC Day 1
16:05:18 <AutomatedTester> Chair: AutomatedTester
16:05:43 <AutomatedTester> Agenda:https://www.w3.org/wiki/WebDriver/2020-TPAC
16:05:58 <AutomatedTester> Scribe: David Burns
16:06:05 <AutomatedTester> ScribeNick: AutomatedTester
16:06:09 <AutomatedTester> RRSAgent: nolisten
17:03:12 <jimevans> jimevans has joined #webdriver
17:03:23 <Hexcles> Hexcles has joined #webdriver
17:03:37 <jimevans> present+
17:03:37 <jgraham> present+
17:03:38 <brrian> present+
17:03:38 <Shengfa> present+
17:03:39 <brwalder> present+
17:03:43 <cb> present+
17:03:46 <john_chen> present+
17:05:07 <Honza> Honza has joined #webdriver
17:05:54 <simonstewart> simonstewart has joined #webdriver
17:07:22 <simonstewart> present+
17:07:32 <Honza> present+
17:07:58 <Shengfa> https://browserstack.zoom.us/j/98806831024?pwd=K3JQSVBmanpkeE5uUzd5elBEb1owZz09
17:08:36 <Honza> * jodvarko in the meeting invite
17:08:41 <AutomatedTester> Topic: State of the Union
17:08:46 <AutomatedTester> RRSAgent: listen
17:10:13 <jgraham> RRSAgent: make logs public
17:10:19 <jgraham> RRSAgent: make minutes v2
17:10:19 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/26-webdriver-minutes.html jgraham
17:12:11 <AutomatedTester> AutomatedTester: The WebDriver specification is mostly in maintenance mode and wpt have been improving. THanks to all vendors in this area
17:12:13 <cb> David, should we record this session?
17:14:08 <AutomatedTester> jgraham: SInce TPAC last year, the webdriver specification has been created. It is creating APIs that are not readily available  in webdriver. This works by creating these new APIs that are wanted based on other bit of work based on proprietary APIs
17:14:57 <AutomatedTester> ... We have seen clients, like Selenium, adding new APIs that we think people will need, and seen clients that use directly like puppeteer/playwright/cypress
17:16:00 <AutomatedTester> foolip: Not much to add... the justification from Google is that cross browser and ergonomics are not where we need them to be for anyone
17:16:39 <AutomatedTester> ... from TPAC it would be good to move our near term roadmap to being more longer term
17:17:51 <AutomatedTester> brwalder: In addition to how to start sessions, we have started using CDDL to allow us to generate clients for the new spec
17:18:37 <drousso> drousso has joined #webdriver
17:19:06 <AutomatedTester> simonstewart: in the Selenium project has started work on an "idealised" API for how we use domains and would be good to discuss the modules later
17:19:31 <AutomatedTester> https://docs.google.com/document/d/1zVvIduq6BfmnVvwGdxrT4l9oglUoOl9hscjzJfYO0Sw/edit
17:21:45 <cb> jgraham: to much work is missing from my side to be properly prepared, I will follow up with it soonish but doesn't need to be part of our TPAC meetings
17:23:30 <drousso> present+
17:29:07 <foolip> present+
17:30:07 <jgraham> q?
17:30:35 <AutomatedTester> Topic: BiDi priorities - what do clients requires to move features over
17:31:41 <AutomatedTester> jgraham: This is a question around the transition process to webdriver -bidi. If we want people to move over from webdriver, as an example, to webdriver. What APIs should we start with?
17:32:43 <whimboo> present+
17:32:46 <jgraham> s/webdriver/cdp/
17:32:55 <jgraham> RRSAgent: make minutes v2
17:32:55 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/26-webdriver-minutes.html jgraham
17:33:59 <foolip> q+
17:34:12 <AutomatedTester> AutomatedTester: We need to make sure that we don't break selenium, puppeteer, cypress
17:34:18 <AutomatedTester> q?
17:34:45 <AutomatedTester> jgraham: which features of CDP are you using and are planning to use?
17:35:42 <AutomatedTester> simonstewart: The first thing we do is during session creation to see where the cdp endpoint is and possibly rewrite that endpoint
17:36:01 <AutomatedTester> ... we have been looking at the use cases people are using
17:36:51 <AutomatedTester> ... we have currently added network interception, javascript exceptions, console logging, basic authentication, and DOM mutations
17:37:07 <zghadyali> zghadyali has joined #webdriver
17:37:38 <AutomatedTester> ... we have some domains that we created to get an idealised and have created our own APIs on top
17:37:54 <AutomatedTester> ... we took a very use case approach
17:38:50 <AutomatedTester> jgraham: That's great. When thinking of the spec, there are 2 ways to do this. There are create a session and script execution. Or there is the value added item ontop of WebDriver 1 and 2
17:39:14 <AutomatedTester> simonstewart: this goes back to TPAC 2019, we had use cases discussed
17:39:23 <AutomatedTester> q?
17:39:33 <AutomatedTester> ack foolip
17:40:11 <AutomatedTester> foolip: we could appraoch this to be feature complete but that would be fun but I suggest doing what you suggested
17:40:19 <AutomatedTester> q?
17:40:54 <AutomatedTester> Topic: Async commands
17:41:24 <AutomatedTester> jgraham: THis is going back to a discussion at a previous F2F call
17:42:09 <AutomatedTester> ... basically the way the spec is currently worded, you will always get a response to a command that is sent.
17:42:23 <AutomatedTester> ... Events can always come at any point
17:42:57 <AutomatedTester> ... and if I remember at a previous meeting, I think Apple suggested that these responses could come out of order
17:43:28 <brwalder> q+
17:43:34 <AutomatedTester> ... in a spec we can easily fix this but I want to check if people are ok with this
17:43:37 <AutomatedTester> q?
17:43:38 <drousso> q+
17:43:41 <AutomatedTester> ack brwalder
17:44:08 <AutomatedTester> brwalder: We discussed this in the chromium implementation recently and this makes sense
17:44:24 <AutomatedTester> ... especially for people are using CDP
17:44:41 <AutomatedTester> ... and this would ease the transition for people moving from CDP to bidi
17:45:31 <AutomatedTester> ... this allows for scenarios where people could get a status update on a command and then get a full response when its done
17:45:39 <simonstewart> q+
17:45:48 <AutomatedTester> ... and there are netwrok interceptions scenarios
17:46:04 <AutomatedTester> ... and by not enforcing the order we make the protocol more powerful
17:46:06 <AutomatedTester> q?
17:46:11 <AutomatedTester> ack drousso
17:46:39 <simonstewart> q-
17:46:52 <jgraham> q+
17:46:59 <AutomatedTester> drousso: WebInspector will always return in the order they are send unless explicitly called async
17:47:01 <AutomatedTester> q?
17:47:21 <simonstewart> q+
17:47:48 <brrian> Example async commands in Web Inspector: network callbacks, IndexedDB commands, anything that could take a long time.
17:47:51 <AutomatedTester> jgraham: my question is then... should we make them async explicitly?
17:48:06 <AutomatedTester> q?
17:48:08 <brrian> q+
17:48:10 <AutomatedTester> ack jgraham
17:48:12 <foolip> q+
17:48:19 <AutomatedTester> ack simonstewart
17:48:48 <AutomatedTester> simonstewart: the programming model for the original selenium is not great for the async work
17:49:10 <AutomatedTester> ... and I don't think we need to explicitly mark it as async
17:49:23 <AutomatedTester> jgraham: I think the models are isomorphic
17:50:31 <AutomatedTester> ... if you want to represent the response that could take a long time you could get an empty placeholder and then an event could come later to replace that placeholder, or via an ID
17:51:21 <AutomatedTester> simonstewart: I don't see value in adding this to webdriver http, so we need to add it as purely event driven
17:51:48 <AutomatedTester> q?
17:51:54 <AutomatedTester> ack brrian
17:52:37 <simonstewart> q+
17:52:54 <AutomatedTester> brrian: I would prefer to have it all async but if can 't then we need to definitely show it clearly
17:53:05 <AutomatedTester> ack foolip
17:53:33 <AutomatedTester> foolip: In terms of preferences I would go for everything to be async
17:54:15 <AutomatedTester> ... I think where order is guaranteed we need to make sure that highlight it
17:54:18 <AutomatedTester> q?
17:54:24 <AutomatedTester> ack simonstewart
17:55:01 <AutomatedTester> simonstewart: Its worth calling out that commands are executed in the order they are sent but responses might not come back in that order
17:55:14 <AutomatedTester> jgraham: The natural way of writing this will guarantee that
17:55:38 <AutomatedTester> ... the commands will be executed in order
17:56:36 <AutomatedTester> RESOLUTION: Agreement that we should have commands async and any further discussion can happen in the PRs for this work
17:56:50 <jgraham> RRSAgent: make minutes v2
17:56:50 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/26-webdriver-minutes.html jgraham
17:57:14 <AutomatedTester> Topic: Targets, contexts, realms
17:58:11 <AutomatedTester> jgraham: One of the things to do in an automation protocol we need to know where commands are addressed to
17:58:28 <AutomatedTester> ... e.g. in JavaScript it could be document or a service worker
17:58:48 <AutomatedTester> ... and we wanted to address commands to specific areas
17:59:18 <AutomatedTester> ... e.g. for resizing a window we need to make sure we are in the correct area
17:59:32 <AutomatedTester> ... so the question is what is the shape of the API here?
18:00:13 <AutomatedTester> ... we are taking our cues from CDP here and we want to be close to CDP to maximise moving the ecosystem over to the Bidi work
18:01:40 <AutomatedTester> ... There is an anomaly here from CDP due to it's history likely
18:02:24 <AutomatedTester> ... so using a browser context here would be good but we need to discuss it
18:02:35 <brwalder> q+
18:02:41 <AutomatedTester> ... I have put a PR up at https://github.com/w3c/webdriver-bidi/pull/62
18:04:59 <AutomatedTester> ack brwalder
18:06:05 <gsnedders> github topic: https://github.com/w3c/webdriver-bidi/pull/62
18:06:07 <AutomatedTester> brwalder: To go into a little detail here about how things are model. I agree that some of the things are historical items. It's described as originally by JavaScript debug details
18:06:43 <AutomatedTester> ... I agree that we need a much higher concept here
18:06:57 <AutomatedTester> ... and browser context that makes a lot of sense
18:06:58 <brrian> Enumerating all the context types seems like a fool's errand, new ones get added all the time. Web Inspector now supports JSContext, AudioWorklets, Workers, Web Workers, Service Workers, Extensions/content scripts, and normal pages. I'm sure there will be something next year.
18:06:58 <brrian> 
18:06:58 <brrian> IMO, for the purpose of restricting which commands work for which contexts, it would make more sense to focus on capabilities of a context (has JS, has DOM, etc) and allow introspection of the context type.
18:07:19 <drousso> there's also new types of contexts being created, like worklets
18:07:42 <drousso> and more annoyingly, different worklets have different behaviors about what/where the execution context lives
18:08:03 <foolip> q?
18:08:05 <foolip> q+
18:08:08 <AutomatedTester> ... it makes sense that we have them as addressable
18:08:14 <AutomatedTester> ack foolip
18:08:46 <AutomatedTester> foolip: James could you direct us to the problems that there might be here
18:08:49 <gsnedders> that just implies we need to be able to extend the set, rather than it being impossible to enumerate them? we see similar with IDL which enumerates contexts
18:09:26 <AutomatedTester> jgraham: My main concern is the migration path for clients trying to support both versions of the protocol. E.g. Puppeteer supporting CDP and bidi
18:10:12 <AutomatedTester> ... and I don't want to hit complex pitfalls around multiprocesses
18:11:25 <AutomatedTester> brrian: Enumerating all the context types seems like a fool's errand, new ones get added all the time. Web Inspector now supports JSContext, AudioWorklets, Workers, Web Workers, Service Workers, Extensions/content scripts, and normal pages. I'm sure there will be something next year.
18:11:25 <AutomatedTester> ... for the purpose of restricting which commands work for which contexts, it would make more sense to focus on capabilities of a context (has JS, has DOM, etc) and allow introspection of the context type.
18:12:05 <brwalder> q+
18:12:29 <simonstewart> q+
18:12:47 <AutomatedTester> jgraham: I see the concerns but I dont see the concrete implications of them are
18:12:51 <AutomatedTester> q?
18:13:37 <simonstewart> q-
18:14:06 <simonstewart> It almost sounds like realms have capabilities
18:14:11 <AutomatedTester> brwalder: If we, following what brrian  said, that we make sure that we target anything that follows that area. E.g. Send a javascript to a command that realm that supports javascript realms
18:14:30 <simonstewart> q+
18:14:56 <AutomatedTester> brwalder: we need to make commands forward compatible so new commands just fit in
18:15:01 <AutomatedTester> ack brwalder
18:15:05 <brrian> Other concern (maybe already addressed), are we trying to specify what contexts are top-level and which are not? And the relationship (i.e., a ServiceWorker can't be subcontext of an iframe)
18:15:56 <AutomatedTester> jgraham: I might be misusing the terms
18:16:15 <AutomatedTester> ... and the context is a browsing context and not a JS context
18:17:02 <AutomatedTester> ... I was thinking of them as discrete items based on their capabilities
18:17:16 <AutomatedTester> brrian: Other concern (maybe already addressed), are we trying to specify what contexts are top-level and which are not? And the relationship (i.e., a ServiceWorker can't be subcontext of an iframe)
18:17:39 <AutomatedTester> jgraham: yes, so the service worker wouldnt have a browsing context
18:18:00 <AutomatedTester> q?
18:18:09 <AutomatedTester> ack simonstewart
18:19:15 <foolip> q+
18:20:01 <AutomatedTester> simonstewart: is it possible to reframe the idea of the context in terms of capabilities and you send a command to something that matches the capabilities
18:20:47 <AutomatedTester> jgraham: for clarity, capaibilities here is not Webdriver capabilities
18:20:49 <AutomatedTester> ack foolip
18:21:11 <AutomatedTester> foolip: I assume solutions would be isomorphic
18:21:36 <simonstewart> Getting the list of targets that match a given "feature" seems like a new command
18:21:59 <AutomatedTester> ... if we are targeting command to a realm that matches "features"
18:22:20 <AutomatedTester> simonstewart: so if there a command takes a union, not 2 targets
18:22:27 <AutomatedTester> foolip: that makes sense
18:22:27 <jgraham> q+
18:22:38 <AutomatedTester> ... what is the complexity we are trying to reduce here?
18:23:33 <AutomatedTester> simonstewart: [reads what brrian mentioned earlier in this topic]. So we have the problem of forward compatibility
18:23:53 <AutomatedTester> ... and realms seem like a specialised feature here
18:24:12 <AutomatedTester> ... and brwalder mentioned earlier that we would feature matching (pattern matching)
18:24:23 <brwalder> was paraphrasing brrian
18:24:34 <foolip> q?
18:25:09 <AutomatedTester> ack jgraham
18:25:32 <AutomatedTester> jgraham: I think this is describing all the same thing
18:25:45 <AutomatedTester> ... a realm has the ability to execute JS
18:26:12 <AutomatedTester> ... and browsing context has the everything including the realm
18:26:45 <AutomatedTester> ... so you could execute JS in a browsing context and it automatically finds the realm
18:27:06 <AutomatedTester> ... so the features model is what we want to follow
18:27:24 <AutomatedTester> ... and there are likely to be "specialisations"
18:28:17 <foolip> q+
18:28:18 <AutomatedTester> ... so it will do the thing or it will error loudly. E.g. Get a DOM node or error out saying you can't
18:29:25 <AutomatedTester> ... do we think that we have a model here that we actually execute?
18:29:43 <AutomatedTester> simonstewart: When we have something to play with we can have more of a discussion
18:29:45 <AutomatedTester> q?
18:29:50 <AutomatedTester> ack foolip
18:30:26 <AutomatedTester> foolip: what is the decision that we are facing here?
18:31:18 <AutomatedTester> jgraham: The current design looks fine. There might be changes in the future when we get more concrete use cases
18:32:10 <brwalder> q+
18:33:08 <AutomatedTester> foolip: I am struggling to think through the heirarchy of things and then how to go down and then targeting
18:33:58 <brwalder> q-
18:34:01 <AutomatedTester> jgraham: there is no doubt that we need to inform the user what the realm is.
18:34:42 <AutomatedTester> ... and this is more of spec organisation issue
18:35:34 <AutomatedTester> ... so if another spec adds a new realm we handle it it fits into this set of features
18:35:47 <AutomatedTester> q?
18:37:25 <AutomatedTester> RESOLUTION: Treat browsing context and realms as 2 concepts. Ensure the model is extensible to future items. This is not a great summary
18:37:34 <brrian> lol
18:39:18 <AutomatedTester> Topic: Script Execution
18:39:48 <AutomatedTester> https://github.com/w3c/webdriver-bidi/issues/18
18:39:59 <AutomatedTester> Github Issue: https://github.com/w3c/webdriver-bidi/issues/18
18:40:49 <AutomatedTester> github-bot: end topic
18:41:19 <brwalder> https://github.com/w3c/webdriver-bidi/issues/16 looks like its related to the PR
18:41:35 <AutomatedTester> jgraham: We have just been discussing realms
18:42:04 <AutomatedTester> ... one of the items that we need to do to prove out the spec is add out support executing script
18:42:17 <AutomatedTester> ... There are a few questions:
18:42:26 <AutomatedTester> ... How do we serialise data?
18:43:11 <AutomatedTester> Github Issue: https://github.com/w3c/webdriver-bidi/pull/57
18:43:19 <AutomatedTester> https://github.com/w3c/webdriver-bidi/pull/57
18:44:26 <AutomatedTester> ... Should we follow the like the webdriver http approach using `arguments`
18:44:56 <AutomatedTester> simonstewart: how adrift are we from the webdriver http serialisation
18:45:09 <AutomatedTester> jgraham: it is different to how devtools approaches
18:45:38 <AutomatedTester> ... it will return a handle to a value so you pass that on and then carry on
18:46:21 <AutomatedTester> ... and thing like CDP has the N+1 problem around `querySelectorAll` that it needs a iterator that does N+1 loops
18:46:51 <AutomatedTester> ... and there are improvements to CDP how to improve things
18:47:21 <AutomatedTester> ... and this fronts it
18:48:41 <foolip> https://chromedevtools.github.io/devtools-protocol/tot/Runtime/#method-evaluate is what I've been looking at. `returnByValue` is what turns JSON serialization on/off. I'm not sure what `generatePreview` does, maybe that has something
18:48:59 <AutomatedTester> simonstewart: If you return a list via Execute Async it would return a handle to the list and then a handle to each item in the list that you need to collect
18:49:27 <AutomatedTester> jgraham: that is correct.
18:49:53 <AutomatedTester> brwalder: The `generatePreview` just gives a "shape" of that can be returned
18:50:28 <AutomatedTester> simonstewart: doing N+1 can be a lot of work if you have a service provider like BrowserStack/Saucelabs
18:50:30 <AutomatedTester> q?
18:51:01 <AutomatedTester> simonstewart: is there a reason why aren't using the webdriver HTTP serialisation?
18:51:25 <AutomatedTester> jgraham: yes, there are times we want to return a handle to JSON objects as well
18:51:40 <AutomatedTester> ... we want to try have the best of CDP and WEbdriverHTTP here
18:52:20 <AutomatedTester> foolip: could someone explain the webdriver http approach?
18:53:22 <AutomatedTester> simonstewart: the tl;dr is if it is a basic type return that, if its a webelement return the UUID that represents it. It expands objects to JSONObjects.
18:53:29 <AutomatedTester> ... there is special casing for windows
18:53:45 <foolip> Is it https://w3c.github.io/webdriver/#dfn-json-clone?
18:54:05 <AutomatedTester> jgraham: its `JSON.stringify` but special handling for windows and elements?
18:54:18 <AutomatedTester> foolip: that feels differnt to James proposal
18:55:20 <foolip> q?
18:56:14 <AutomatedTester> jgraham: WebDriver HTTP would fail in cases where they can't be serialised like cyclic elements etc
18:57:17 <AutomatedTester> simonstewart: we need to prevent too many roundtrips as possible with cloud providers
18:57:48 <AutomatedTester> jgraham: there are cases we need to think about it like WASM in the future
18:58:42 <AutomatedTester> ... how do protocols return multiple values async
18:59:01 <AutomatedTester> drousso: in webinspect you have 1 opportunity to return a value
18:59:23 <AutomatedTester> ... it gets the completion value as in ecmascript
18:59:38 <AutomatedTester> ... if you need multiple returns you need to do something special
18:59:44 <foolip> https://chromedevtools.github.io/devtools-protocol/tot/Runtime/#method-evaluate indeed has an `awaitPromise` parameter
18:59:53 <AutomatedTester> ... but you could do await promises
19:00:31 <AutomatedTester> foolip: that's the same model that CDP does
19:01:20 <AutomatedTester> drousso: there are ways we can try solve it but it's never been a use case that people wanted
19:02:01 <foolip> the sort of model that exists in https://streams.spec.whatwg.org/ might be worth looking at
19:02:02 <AutomatedTester> ... you could have your code return a generator
19:04:14 <jgraham> RRSAgent: make minutes v2
19:04:14 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/26-webdriver-minutes.html jgraham
19:05:52 <jgraham> RRSAgent: stop