14:32:58 RRSAgent has joined #webdriver 14:32:58 logging to https://www.w3.org/2022/09/15-webdriver-irc 14:33:20 RRSAgent (IRC): help 14:33:50 RRSAgent: silence 15:07:03 meeting: TPAC 2022 - Browser Testing and Tools 15:07:26 chair: David Burns 15:11:03 rrsagent: silence 19:55:46 RRSAgent has joined #webdriver 19:55:46 logging to https://www.w3.org/2022/09/15-webdriver-irc 19:55:55 Zakim has joined #webdriver 19:56:05 meeting: TPAC 2022 - Browser Testing and Tools 19:56:17 Chair: AutomatedTester 19:56:24 Agenda: https://www.w3.org/wiki/WebDriver/TPAC-2022 19:56:31 Scribe: David Burns 19:56:36 ScribeNick: AutomatedTester 19:56:55 rrsagent: make logs public global 19:57:22 rrsagent: make logs public world-visible 19:57:38 rrsagent: make logs world-visible 19:57:46 rrsagent: make minutes 19:57:46 I have made the request to generate https://www.w3.org/2022/09/15-webdriver-minutes.html AutomatedTester 19:57:50 present+ 20:03:37 BrandonWalderman has joined #webdriver 20:04:32 Hi folks. Zoom wants a passcode but I don't see one at https://www.w3.org/events/meetings/d7ec73b1-f9b3-4748-a508-eec1f9751d9a how can I join the meeting? 20:04:45 https://us02web.zoom.us/j/3919679751?pwd=SGY5WFpSSFBRN0lyVFo0MGhFT1R3QT09 20:04:47 karlcow has joined #webdriver 20:04:50 that worked for me 20:04:58 present+ 20:05:10 present+ 20:05:23 present+ 20:05:31 present+ 20:06:54 I'm still in Berlin 20:07:09 present+ 20:08:28 "meeting host will let you in soon" 20:09:26 thanks im in 20:09:47 LanWei has joined #webdriver 20:10:04 https://www.w3.org/wiki/WebDriver/TPAC-2022 20:10:11 RRSAgent: make minutes 20:10:11 I have made the request to generate https://www.w3.org/2022/09/15-webdriver-minutes.html jgraham 20:10:18 present+ 20:10:26 RRSAgent: start logging 20:10:26 I'm logging. I don't understand 'start logging', jgraham. Try /msg RRSAgent help 20:11:12 I’ve been caught away from my office. I will join once I return. Perhaps in about 45 minutes. 20:12:14 Agenda: https://www.w3.org/wiki/WebDriver/TPAC-2022#Agenda 20:13:19 Topic: ARIA-AT progress update 20:14:20 https://docs.google.com/document/d/1zALOhEIOn8BIdId3oO8nqjdgDz-hWjjLSj7Do7db1gU/edit?usp=sharing 20:14:25 sethtompson: I would like to start presenting 20:14:33 patrickangle has joined #webdriver 20:14:43 ... [introductions of team and working on ARIA] 20:15:10 ... the problems with testing ARIA at scale is similar to wpt 20:15:17 ... and test262 20:15:53 ... we joined the BTT wg last December to explain our plan and ideas 20:16:35 ... [explains what they wanted and the protocol] 20:16:56 ... we have a draft protocol document that is very similar to webdriver bidi 20:17:21 ... we want to reuse as much as possible for ease and interoperability 20:17:44 ... there is a link to a bikeshed preview 20:17:52 https://github.com/w3c/aria-at-automation 20:17:59 Spec preview https://pr-preview.s3.amazonaws.com/w3c/aria-at-automation/pull/25.html 20:18:54 ... we've added protocol, the vendor specific settings, and then the bulk of the work is a milestone on how we capture the spoken word 20:19:19 ... and the last milestone we have reached is methods to simulate keypresses 20:19:52 ... this is the bare minimum requred to be able to do automation 20:20:03 ... there is more work that we would like to do 20:20:52 ... the remaining milestones are activating commands, internal states, and headless mode 20:21:39 ...t 20:21:49 ... this is the overview so far 20:22:05 ... and we have started working on NVDA 20:22:16 ... and seeking a 2nd implementation 20:22:17 q? 20:22:57 ... questions for BTT: soliciting feedback from this wg 20:23:03 ... working relationship between the two specs 20:23:05 q? 20:23:19 present+ 20:23:36 zcorpan (IRC): that covers it... the integration between ARIA-AT and Webdriver is an open question 20:23:50 q+ 20:23:59 ... it seems useful to be able to use both protocols in a test 20:24:05 ack next 20:24:41 jgraham (IRC): having read the spec there are a number of areas that copies webdriver 20:25:00 ... it would be good to have a way for you to reference ours instead of duplicating things 20:25:39 ... and since we're going to speaking to 2 different applications at the same time, there will be 2 ports open in 2 applications and I can't see there being any major issues 20:25:47 zcorpan (IRC): I agree this seems possible 20:26:01 ... I guess the question is how would set this up in practise 20:26:37 ... how would you set up a session that you can use both tools at the same time... it could be tricky 20:27:02 jgraham (IRC): if you wanted to multiplex this over 1 connection then this could get tricky 20:27:10 q+ 20:27:51 ... I am assuming that you want to to a service one 1 port and then it can get tricky 20:27:59 ack next 20:29:53 AutomatedTester: I think part of the problem is posibly not solvable by this group, but it might be useful to chat to the Selenium community who have experence of building out this kind of scalable system. Ports are fairly cheap, so it might not be a major issue [to use two]. I'm happy to faccilitate such a discussion if you want. 20:31:10 zcorpan (IRC): to jgraham (IRC) point on duplication, since we only have 1 implementation that seems fine but in the long term we should it live in this WG 20:31:15 q? 20:33:20 automatedtester: I don't see an issue with this living in this wg but I will need to speak to Mike 20:34:42 jgraham (IRC): we will definitely take patches on how to handle the references and work from there. I think we will need to just figure out the logistics 20:34:45 q? 20:36:27 Topic: WebDriver-classic review process 20:36:39 Github: https://github.com/w3c/webdriver/issues/1681 20:37:31 jgraham (IRC): I will take this. The topic is about getting review to the webdriver spec 20:37:41 ... there are 2 reasons this relevant 20:38:03 ... 1) we are adding features and bug features to the classic support 20:38:22 ... 2) and this can block bidi 20:39:17 ... in bidi where there are things duplicated we should reference things in the classic 20:39:57 ... so we have a few issues that are waiting 20:40:23 ... and there are PRs blocking working on bidi 20:41:09 ... as it says in the issue 20:41:53 ... there are only 3 codeowners... are we only expecting these people? How can we add new reviewers 20:42:19 q+ 20:44:13 AutomatedTester: Are those the only people who can review? No. If there are other people we should add them, and help them get started. One suggestion is that if these items are blocked and discussed in the BiDi editorial meeting and there's consensus then we could use that approval to get them landed. I'm happy to help make the process simpler. 20:45:26 jgraham (IRC): so my question for sadym (IRC) and Brandon Walderman what can we do to make you feel comfortable in reviewing these PRs? 20:45:48 Brandon Walderman: for my role in Edge on bidi, things have been scaled back at MS 20:46:07 ... I am happy to help with reviews but can't commit to more 20:47:09 sadym (IRC): I have the opposite issue, I can get more into the reviews... the issue is trying to get up to speed but I am happy to get up to speed more 20:47:55 patrickangle: I would also be happy to review classic as I have been working on that implementation (at Apple) 20:47:58 q+ 20:47:59 q+ 20:48:06 q+ 20:48:08 ack 20:48:14 ack next 20:48:21 ack next 20:48:31 q+ 20:49:24 ack gsnedders 20:49:27 Sam Sneddon [:gsnedders]: some of the reason I haven't done this is because there are items that have made things just sit there and I haven't felt like doing more... but if we are actively doing things then I am happy to help too 20:49:32 ack next 20:50:16 jgraham (IRC): I think we have a comms issue here and we need to make sure that we flag these things in editorial meetings moving forward 20:50:46 ... maybe we set a process for review priority 20:51:32 ... the other question is around the codeowners, do we want it or deleting it? 20:52:13 AutomatedTester: Happy to move towards a BiDi approach 20:52:40 AutomatedTester: We should try to keep things as simple as possible and use the same processes for both specs 20:52:44 q? 20:52:49 q+ 20:52:56 ack next 20:53:33 sadym (IRC): a bit off topic; what is the process I try prototype it and then give review 20:54:12 ack next 20:55:53 jgraham (IRC): from the classic point a lot of things are refactors in the queue, so we don't need to have people trying to implement it 20:56:35 action: remove CODEOWNERS from the repo 20:56:55 action: add label for items that need to be reviewed in the next editorial meeting 20:57:47 topic: Actions IME support 20:58:06 github https://github.com/w3c/webdriver/issues/1683 20:58:32 github: https://github.com/w3c/webdriver/issues/1683 20:59:02 jgraham (IRC): This is also relevant to webdriver classic 21:00:35 ... the issue here is a proposal on how to handle ime input in webdriver 21:00:48 ... IME is input method editor 21:01:13 ... it is commonly used in languages where you can't type the characters directly 21:01:52 ... [describes examples] 21:02:22 ... there are a lot of web compat issues in editor libraries because they can't test IME 21:02:53 ... [describes input breakage in Gecko] 21:03:39 ... for those who have heard of Interop 22... part of that is working on interop in input 21:05:53 ... in webdriver, the lowest level inputs is actions that allows you to send through the keyboard, pointer events and so on 21:07:06 ... with IME you press a key and that intercepts and a different event is fired. e.g. A would change it to the keycode and then do composition 21:07:31 ... the webpage gets composition events 21:07:56 ... [explains different composition methods] 21:08:16 ... the proposal is we add a new input type called IME 21:08:39 ... this has 2 actions, `compositionUpdate` 21:09:18 ... the other action is `compositionEnd` 21:10:06 ... so the webdriver specific thing that's not clear how these things hook together 21:10:38 ... [explains IME and Keyboard] 21:11:45 q+ 21:11:45 q? 21:11:47 q+ 21:12:08 ack 21:14:27 AutomatedTester: Historically WebDriver (Selenium) had IME support built in. It was handled by actions trying to inject directly into the event queue. There was special C++ code required to handle it. That's why we didn't do this and focused on US keyboard input. We did allow actions to handle sending specific unicode characters so you could input final composed characters. 21:14:45 AutomatedTester: Required specific install on the machine. 21:14:59 AutomatedTester: Is it easier to implement now? 21:15:21 AutomatedTester: High level actions seem OK, but is it implementaale? 21:15:25 ack next 21:15:28 s/aa/ab/ 21:16:01 jgraham (IRC): this is a case benefits being supported directly in the browser 21:16:26 ... the proposal is it is at the moment... it's a mid layer proposal 21:16:49 ... we won't go to the OS IME 21:17:21 ... we will provide enough data to the browser so it could inject the relevant events 21:18:40 ... this should be implementable and it can be implemented in gecko 21:19:25 q+ 21:19:33 ... [explains how we need to maintain some states] 21:19:59 ack next 21:20:22 Brandon Walderman: I support this feature request 21:21:01 ... we had an intern do some of this in Chromium for CDP 21:21:49 ... the building blocks are already in chromium so it's a case of adding this to chromedriver 21:22:25 ack next 21:22:50 Lan Wei: I was working on the actions implementation 21:23:11 ... we have looked at this and it's very hard to implement 21:23:21 ... could you explain the client API 21:23:35 jgraham (IRC): so from the point of view of webdriver user 21:23:52 ... it doesn't ever interact with an IME on the machine 21:24:00 ... we will emulate it 21:24:48 q+ to ask about gecko on different platforms 21:25:06 Lan Wei: do you have language type as an input 21:25:53 jgraham (IRC): the proposal doesnt have a way to handle any configurations... e.g. different IMEs handle different combinations to get a different order of events 21:26:15 Lan Wei: do you have any plan on when we want to work on this API? 21:26:48 jgraham (IRC): since this is part of Interop 2022, there is pressure to get this done quickly 21:27:12 ... we would love feedback now 21:27:16 q? 21:27:23 ack next 21:27:24 karlcow, you wanted to ask about gecko on different platforms 21:28:02 karlcow (IRC): I wanted to ask jgraham (IRC) ...do we need a different test per platform? 21:28:25 jgraham (IRC): if platform IMEs handle things different then a test per platform? 21:28:36 karlcow (IRC): how do you make this universal? 21:28:44 jgraham (IRC): this is very hard... 21:29:15 ... it won't adress all cases but it's an improvement since we have zero way to test 21:29:22 q? 21:31:00 Break for 15 minutes 21:33:09 karlcow has joined #webdriver 21:54:14 karlcow has joined #webdriver 21:56:00 topic: Shared element references 21:56:19 github: https://github.com/w3c/webdriver/issues/1594 21:57:41 jgraham (IRC): the title of this issue is very misleading 21:57:53 ... for webdriver when we return an element or send an element 21:58:02 ... we check is the element in the DOM and attached 21:58:14 ... if not we return `StaleElementReference` 21:58:41 ... when working on trying to make sure that the cache of elements is shared between classic and bidi 21:59:00 ... for bidi we have decided that we don't want to add this 22:00:00 ... [explains example of across windows] 22:02:17 ... [explains that we shouldn't be allowed to share things across origins] 22:02:45 ... the question is how do we explain this in the spec 22:04:20 automatedtester: what does this mean in 'accessible'? 22:04:35 jgraham (IRC): this means browser context group I think 22:05:26 ... the questions are Do we disagree with assumptions in there? 22:06:19 ... and "how do this relate to PR 180 in the bidi spec" 22:06:21 q? 22:06:39 q+ 22:06:44 https://github.com/w3c/webdriver-bidi/pull/180 22:07:50 AutomatedTester: If we remove StaleElementReference, and make it per browsing context group, what is the impact on compat? 22:08:16 ... this could impact Selenium users. 22:09:04 jgraham (IRC): I forgot to explain, this wouldn't have any normative changes. WebDriver would still work as it does today 22:09:19 q? 22:09:25 ack next 22:09:26 q+ 22:09:29 But WebDriver-BiDi would allow a superset of the WebDriver behaviour 22:09:34 ack next 22:09:56 Jim Evans: as I am thinking about it and I will talk mostly from Selenium use case 22:10:35 ... if we look at a SPA where doing an action on the page that causes a refresh 22:11:09 ... people are using that stale element as a sychronism point 22:12:22 ... in the classic we aren't changing things but how would we create this type of test in the bidi world 22:12:44 jgraham (IRC): the first thing classic doesnt' change 22:13:10 ... at a high level we should be encouraging people to look for specific events that they can use 22:13:18 ... instead of using polling 22:14:31 ... if people pass in a element id and it's been GC'ed then it wouldn't be able to deserialise and error 22:15:06 ... and since we want to implement classic on top of bidi we need to make sure it works 22:15:30 Sam Sneddon [:gsnedders]: so would the connected check be an extra bidi call? 22:15:46 jgraham (IRC): yes as things are now 22:16:17 Sam Sneddon [:gsnedders]: so it looks like we need to implement it but it's implementable 22:16:33 ... [discusses a possible solution with tree walking] 22:17:48 jgraham (IRC): I'm not concerned about our ability to support these use cases 22:18:31 ... the question is what we want bidi to do and the state of where sadym (IRC) is at 22:19:09 Jim Evans: This does answer my question. I wonder if there is mileage in having an event in sent when an element is removed from the DOM 22:19:28 jgraham (IRC): in the spec there is seriealization of a node 22:19:37 q+ 22:19:41 ... in terms of getting an event when a node is removed 22:20:03 ... I would expect people to install a script to do mutation observers 22:20:30 ... it might not be a primative but a combination of features 22:20:33 q? 22:20:36 ack next 22:20:54 sadym (IRC): so I when I wrote the spec for shared ID 22:21:25 ... I wrote it that it didn't care if the element was in the DOM but where it is now 22:22:22 jgraham (IRC): my understanding of shared id is that as long it hasn't been GC'ed it will be able to send the element back 22:23:16 ... so you can see if the element is there by trying to deserialise and can't it's not then we can error 22:23:43 ... or if we return something we can see if the parent is a document to see if it is in the document 22:23:45 q? 22:23:56 https://developer.mozilla.org/en-US/docs/Web/API/Node/isConnected 22:24:59 AutomatedTester: A question I have is to get to the same state as StaleReference might require 3 wire calls. That's a lot of round trips for cloud providers. Is that correct? 22:25:55 q+ 22:26:51 jgraham (IRC): if you are implement element selected? In this case you could do this as execute 22:27:22 ... but if it's returned from a different method classic would fail quickly but bidi would need to do an extra call 22:28:21 ... but in the common case it should hopefully be equal between the two modes 22:28:29 ack next 22:29:05 sadym (IRC): what is the scenario when the user wants to get the stale state in bidi 22:29:17 ... to me it seems exotic 22:29:44 q+ to mention why we have the connectedness test originally 22:29:45 ... there is a web api 22:30:24 jgraham (IRC): [repeats Jim Evans example and explains] 22:31:16 ... there is a DOM api that people can use to check the connectedness 22:31:55 ... the observable difference is in classic, if you find an element refresh it would error 22:32:27 ... in bidi it wouldn't error without doing a number of checks 22:33:21 ... we could not implement this info but it makes classic on top of bidi slightly more complex 22:33:29 q+ 22:33:40 ... and it could be racy 22:33:45 ack next 22:33:47 gsnedders, you wanted to mention why we have the connectedness test originally 22:34:19 karlcow has joined #webdriver 22:34:24 Sam Sneddon [:gsnedders]: why do we have the connectedness tests? 22:35:28 ... provided we aren't concerned with implementing this without weakmaps then we don't need to worry 22:36:16 ... [explains example web component in a SPA] 22:37:14 ... can we change the semantics of stale reference/ I expect no 22:37:19 automatedtester: no we cant 22:37:22 q? 22:37:26 ack next 22:37:42 gsnedders' use case of a SPA implementing a component cache is useful. 22:37:52 Jim Evans: for clarification I will reiterate 22:38:19 ... there are a number of APIs for element state and element interaction that will require an extra round trip 22:38:31 jgraham (IRC): not necessaryly 22:39:26 Jim Evans: in the case of element rect example, if people do that and it's not attached they will get a stale reference and then people do that extra test 22:39:48 q? 22:39:59 ... specifically for webdriver classic on bidi 22:40:29 Sam Sneddon [:gsnedders]: if we need to walk the tree then in bidi it would be very expensive 22:41:37 jgraham (IRC): in the script that we can just add 1 more line for connectedness 22:41:52 ... but in the executescript case it will be a lot more that needs to be done 22:42:52 q+ 22:43:19 ... [discussion around executeScript and how this could impact networks etc] 22:45:04 Question is "can we ever end up running user code during JSON serialization in classic that would allow us to observe teh difference between bailing early with a stale element reference and doing the full serialization and then later checking for stale elements?" 22:45:15 q? 22:45:20 ack next 22:46:17 sadym (IRC): you can get a stale reference when you try access that element is that correct? 22:46:30 jgraham: Oh, no, we do serialise accessor properties, not just data properties, so "yes". 22:46:41 jgraham (IRC): I think it might also error when doing a serialisation 22:48:11 sadym (IRC): so chromedriver keeps a map of the guid and tries to access it on cdp and if its not there it throws stale element 22:48:38 jgraham (IRC): if chromedriver isn't following the spec exactly here we might be able to change the sematics slightly here and get away with it 22:48:39 q? 22:48:46 https://w3c.github.io/webdriver/#dfn-json-clone is the serialization algorithm from classic and it does check if the element is stale 22:49:27 jgraham (IRC): sadym (IRC) do you have a status update on PR 180 22:49:38 https://github.com/w3c/webdriver-bidi/pull/180 22:50:14 sadym (IRC): I have an action to look at how chromedriver should would 22:50:20 s/would/work 22:50:54 ... I have changed priorities since then so would need to check on it 22:51:05 jgraham (IRC): do you have any outstanding items on that pr? 22:51:17 sadym (IRC): I can't remember the state of this 22:52:04 ... I think there are actionable items there that I need to work on 22:54:07 Topic: Closing the browser 22:54:30 karlcow has joined #webdriver 22:54:32 github: https://github.com/w3c/webdriver-bidi/issues/119 22:54:40 motokim has joined #webdriver 22:55:20 q+ 22:55:29 q+ 22:55:34 jgraham (IRC): The question on this topic is "should we allow people to close the borwser?" 22:55:58 ... forcible quits might not clean up things as people expect 22:56:32 ... since we aren't stopping multiple sessions then 1 session could kill other sessions 22:56:55 q+ 22:57:04 ... the second question is "Should closing the last browsing context shutdown the browser"? 22:57:10 q? 22:57:18 ack next 22:57:55 Sam Sneddon [:gsnedders]: in MacOS applications are singletons so safari automation is running in the same safari as users 22:58:09 q+ 22:58:39 ... but quiting the entire browser kills all sessions and I think that is unacceptable 22:59:01 ack next 22:59:23 Jim Evans: I am want this primative 22:59:38 ... in the last 2 days I have been working on a bidi client 22:59:57 ... I am able to use Firefox to get things working 23:00:34 ... but I don't have a mechanism to kill the browser that could leave things in an incomplete state 23:00:40 q? 23:00:44 ack next 23:01:32 sadym (IRC): my question is why shouldnt we just close the windows that automation has control over 23:02:32 Sam Sneddon [:gsnedders]: when the session is closed we close the windows under automation control? 23:02:50 sadym (IRC): if there are more than 1 session? 23:02:57 Sam Sneddon [:gsnedders]: we only allow 1 session 23:03:06 ... but I will defer to patrickangle 23:03:42 patrickangle: we have things we need to untangle to support multiple sessions 23:04:31 sadym (IRC): for quit we only need close the automation that should be fine? 23:04:44 Sam Sneddon [:gsnedders]: it depends on how we spec the sematics 23:05:27 jgraham (IRC): I agree what people want for desktop is that the browser process has shut down 23:05:34 s/sematics/semantics/ 23:05:40 ... and it makes sense that this is not always implementable 23:06:15 ... in bidi one could observe all the windows 23:06:41 ... but I would expect apple would split what you can and can't observe 23:06:52 s/apple/safari/ 23:07:56 ... for most use cases it would be sufficient that we just say that all automation windows are closed and shutdown 23:09:43 q+ 23:09:58 ... I would expect the spec that we spec out that we close it all the automation windows 23:10:21 ack jgraham 23:10:30 Sam Sneddon [:gsnedders]: it's not just safari that is a singleton app... all browsers are 23:10:54 ... so all browsers can have this problem and you can get around it would be weird 23:11:02 s/all browsers are/all browsers are on macOS/ 23:11:14 ack next 23:11:14 s/all browsers are on macOS/all applications are on macOS/ 23:11:24 RRSAgent, make the minutes 23:11:24 I have made the request to generate https://www.w3.org/2022/09/15-webdriver-minutes.html gsnedders 23:12:10 Jim Evans: I think your assessment that the close on the browser closing all the automation windows is fine 23:12:22 ... but from a test author point of view 23:12:47 ... I can ensure restore state when the test is finished that the machine is back to the same state 23:13:22 q+ 23:13:32 ... if this isn't the case then it will cause issue reports if we leave anything behind 23:13:52 ... and those issues will just be forwarded to the spec 23:13:57 ack next 23:14:29 jgraham (IRC): i think the sematics is we drop state of anything related to webdriver 23:14:56 ... i think I agree that people will find it will be weird if we don't kill things 23:15:22 ... but there are times where we can't fully kill things e.g. FirefoxOS/ChromeOS/KiaOS 23:15:24 q+ to mention alternative suggestion 23:16:10 ... I think we can add something to help clients "clean up the webdriver state' 23:16:18 q? 23:16:30 ack next 23:16:31 gsnedders, you wanted to mention alternative suggestion 23:17:13 Sam Sneddon [:gsnedders]: my proposal is we have a flag that opts into closing all browsers that is fallible in an implementation specific way 23:17:51 ... [explains how this could look using Safari based on state of different things] 23:18:12 jgraham (IRC): yea. that's fine, but it also doesn't need a flag 23:18:46 q+ for a quick poll of implementors before we end 23:19:11 ... we need to think about mobile and we might not be able to get PID etc and wait for that 23:19:16 ... or return that info 23:19:28 q? 23:19:31 ack next 23:19:32 JimEvans, you wanted to discuss a quick poll of implementors before we end 23:19:53 Jim Evans: the bidi spec has a definition of a bidi only session 23:20:01 ... Firefox has an implementation 23:20:29 ... can we expect bidi only sessions in all browsers? 23:21:19 Sam Sneddon [:gsnedders]: we can't comment on what is going into a future safari release 23:21:44 sadym (IRC): technically you can do that now in chrome 23:22:01 https://github.com/GoogleChromeLabs/chromium-bidi 23:22:09 Brandon Walderman: edge will follow chromium 23:22:16 q? 23:22:18 q+ 23:22:58 ack gsnedders 23:23:07 q+ 23:23:56 Sam Sneddon [:gsnedders]: going back to the comment on option that could be a capability to request a completely isolated instance would make sense 23:24:22 ... for most that's a easy capability to satisfy 23:24:28 ack next 23:25:19 to @JimEvans: WebDriver BiDi in Chromium could be used via ChromeDriver (classic+BiDi) or via Mapper (BiDi only) 23:25:19 https://github.com/GoogleChromeLabs/chromium-bidi 23:25:20 jgraham (IRC): I am trying to think how a client would do things? clients would have to understnad what it is speaking to 23:25:24