11:52:05 RRSAgent has joined #webdriver 11:52:09 logging to https://www.w3.org/2023/06/14-webdriver-irc 11:52:18 Zakim has joined #webdriver 11:54:20 Meeting: WebDriver Roadmap 2023+ 11:54:31 Chair: David Burns 11:54:57 Agenda: https://www.w3.org/wiki/WebDriver/2023-06-BiDi-roadmap 11:55:10 Scribe: David Burns 11:55:18 ScribeNick: AutomatedTester 11:55:48 RRSAgent: set logs world-visible 11:56:42 RRSAgent: publish minutes 11:56:43 I have made the request to generate https://www.w3.org/2023/06/14-webdriver-minutes.html AutomatedTester_ 12:03:31 present+ 12:04:04 jgraham_ has joined #webdriver 12:04:27 present+ 12:04:34 present+ 12:04:46 present+ 12:04:52 Meeting: WebDriver Roadmap 12:05:07 present+ 12:05:11 present+ 12:05:15 Agenda: https://www.w3.org/wiki/WebDriver/2023-06-BiDi-roadmap 12:05:19 present+ 12:05:20 RRSAgent: make logs public 12:05:26 RRSAgent: make minutes 12:05:27 I have made the request to generate https://www.w3.org/2023/06/14-webdriver-minutes.html jgraham_ 12:05:58 present+ 12:06:13 lola has joined #webdriver 12:06:23 present+ 12:06:34 present+ 12:06:37 rcaliman has joined #webdriver 12:07:21 q? 12:08:54 https://www.w3.org/wiki/WebDriver/2023-06-BiDi-roadmap 12:11:29 simons has joined #webdriver 12:11:40 present+ 12:11:50 topic: WebDriver BiDi status in browsers 12:12:35 whimboo: I will give a brief overlook of the Firefox implementation 12:12:38 ... we have implemented network logging events 12:13:09 ... we also implemented the preload scripts API 12:13:25 ... this can be used for script pinning in selenium 12:13:59 ... we have also added for full user interactions APIs 12:14:24 ... we support all inputs except pen at the moment 12:15:03 ... puppeteer has added capability matching for session.new 12:15:16 ... we are next going to be working on ending a session 12:15:32 ... and jgraham is working on the network interception part of the specification 12:15:46 ... and will also start working on modal dialogs 12:16:28 sadym (IRC): from Google, we have been working on screenshots and PDF generations 12:16:46 ... we are working actively on network events and network interceptions 12:17:00 ... we are also working on proper serialisation 12:17:27 ... and we are working on the user inputs APIs 12:18:33 Sam Sneddon [:gsnedders]: we, webkit, have not shipped anything yet and we do not comment on any future releases. 12:19:54 Topic: WebDriver BiDi implementations in browsers 12:20:08 Topic: WebDriver BiDi implementations in browsers 12:20:41 whimboo: before we start on the roadmap I wanted to talk about the follow as it will help with the implementation 12:20:57 ... I have created the following spreadsheet https://docs.google.com/spreadsheets/d/1bkiPU5eDBCqFkx5p_VSBx_OK8gy9TeHRKQVPHKMATGQ/edit?pli=1#gid=0 12:21:46 ... we have been working on this and documenting what features are implementecd and in what version it was implemented in 12:22:12 ... so would others find it helpful to keep this up to date 12:22:55 sadym (IRC): we have an internal document that is similar and we are happy to add more details to this to keep it up to date 12:23:09 Topic: Puppeteer for Firefox over WebDriver BiDi 12:23:30 nechaev has joined #webdriver 12:23:39 whimboo: in this spreadsheet is more targetted for puppeteer and firefox https://docs.google.com/spreadsheets/d/1jFODscDeaqqnXC3xzMNt2biX0eY7kZ9e-KTs5GPhjG4/edit#gid=0 12:24:19 ... we are tracking all the work that is needed to support all versions of puppeteer over bidi instead of CDP 12:24:49 ... if the Selenium folks want to have a similar discussions and documents that would be good but can be done later 12:24:53 q? 12:25:21 Topic: Roadmap 12:25:31 github: https://github.com/w3c/webdriver-bidi/issues/403 12:26:09 mathiasbynens (IRC): I will get us started on this 12:26:34 ... THere are some draft PRs against the spec of things that need working on 12:26:57 q+ 12:26:57 ... we have some good use cases of what people want 12:27:11 q? 12:27:43 ack next 12:28:16 q+ 12:28:39 jgraham: one weakness of what we ahve done in the past is that we have looked at abstract use cases and not always the client use cases 12:28:59 ... e.g. setEmulation is needed for puppeteer to work and isn't on our roadmap 12:29:18 ... so I think we need to focus on what we can do to get clients using bidi in the short term 12:29:20 ack next 12:29:55 simons: one thing that we should have is to have reformulating webdriver classic on top of webdriver bidi 12:30:15 q+ 12:30:19 ... but figuring out what is missing would be a rich seam of work for us moving forward 12:30:22 q+ 12:30:26 ack next 12:30:32 q+ 12:30:52 whimboo: the last time we did this we started with Selenium and puppeteer needs and work out the priority from there 12:30:57 ack next 12:31:56 mathiasbynens (IRC): the puppeteer needs are documented in this thread here. The top of the issue has things in the order of what we need 12:32:20 simons: could you reformat what you're saying into a use case 12:32:36 ... the use case is mostly for those writing clients and not the end user writing tests 12:33:07 ... in terms of missing functionality, I don't know what's missing but we should try figure out if there are things 12:33:42 mathiasbynens (IRC): but that makes a new audience moving forward 12:33:55 simons: yes I agree 12:34:47 jgraham_ (IRC): the classic spec has a lot of good use cases that people need are there 12:35:00 ... and there is a 2nd level of detail and is lower priority is the ability to make chromedriver use bidi on it's own 12:35:33 ... and I do think that "it must be an end user use case" is ok but I think we can do better 12:35:49 ... I think that making the clients working is a much better approach 12:36:38 ... the priority here is to make sure that we can work and not all use cases come into it. e.g. setEmulation 12:36:41 ack next 12:38:46 mathiasbynens (IRC): should we add simons item on classic reformulation? 12:39:03 jgraham_ (IRC): perhaps but maybe that should be more of a process 12:40:00 q+ 12:40:01 ... I think we should use this and perhaps spreadsheets 12:40:04 https://docs.google.com/spreadsheets/d/1fmPugULnRlsuUGHLnjTdlUWU01X4kkVfrLjj96w_Tcc/edit?usp=sharing 12:40:12 ack next 12:41:01 Sam Sneddon [:gsnedders]: when we are working on things defined on webdriver classic are we discussing the proper spec or the extension points to that spec in other specifications 12:41:14 jgraham_ (IRC): yes 12:42:03 ... some of it is purely browser testing rather than web app testing but I do believe that it is in scope 12:42:21 s/or the extension points/or also the extension points/ 12:46:04 https://docs.google.com/spreadsheets/d/1Cg3rifrBZClIitU3aFW_WDv64gY3ge8xPtN-HE1qzrY/edit#gid=0 12:50:31 lolaodelola has joined #webdriver 13:04:16 q+ 13:05:17 whimboo: you changed "Print screenshot" to "Capture screenshot", but that has different sets of existing implementations in Classic, so we probably need to split them? 13:06:13 Both print and capture are already in BiDi, so if it's specific subfeatures we should call them out 13:06:54 Aren't atoms already handled by preload scripts? 13:07:13 ack next 13:09:11 WebdriverIO has a lot of Appium users that run mobile web tests in emu/simulators 13:10:07 jgraham_: Ah, I missed them being there 🙃 13:10:07 mathiasbynens (IRC): Why don't Selenium/WebDriverIO need device emulations? 13:10:33 automatedtester: Selenium works with those mobile browsers either on real devices or via emulators/simulators? 13:11:36 jgraham_ (IRC): are we talking about viewport or device px or?... I have added a new column to make sure that we have the same understanding of terms 13:11:50 q+ 13:12:30 AlexRudenko: for device emulation the minimum is viewport shaping 13:12:40 ... at the minimum. 13:13:20 ... users struggle with getting the correct window size becauae of the browser chrome impacting the window size 13:13:36 ... in puppeteer it is set as a initial capability 13:13:57 ... window size can impact all tabs in the main window 13:14:03 ... there is a spec proposal 13:14:19 ack next 13:16:40 q+ 13:16:44 ack next 13:17:14 AlexRudenko: it allows you to make a "temp profile" 13:18:06 ... for sandbox. The issue is here is to try help handling the browser start up and creates an "private/incognito" tab which is much faster than restarting the browser 13:19:42 jgraham: this could be interesting to spec as there are no standard way of describing items between browsers. this might not map to profiles... e.g. containers in firefox might be the same here but we don't know 13:21:23 sadym (IRC): webextensions: what we suggest we add the ability to install extensions and access background pages 13:21:49 jgraham_ (IRC): I suggest we split this into 2 tasks 13:22:02 ... loading is 1 and what people might do 13:22:10 ... and debugging is a very different thing 13:22:57 q+ 13:23:06 ack next 13:23:24 whimboo: do we also need uninstall and enable/disable? 13:23:26 q+ 13:23:34 ack next 13:24:04 simons: we definitely install/uninstall as a priority for this item. Enable/disable are nice to haves 13:25:02 AlexRudenko: puppeteer only allows the installation of extesnions 13:26:12 sadym (IRC): get/set/delete of cookies for a specific origin 13:27:13 automatedtester: do we want access to the cookie jar from outside the origin? 13:27:39 jgraham_ (IRC): yes, we need to rethink this as cookies have grown since we did this originally 13:28:28 whimboo: window manipulation: this is similar to device emulation is that we need to manipulate the browser window 13:28:53 ... and then we have window manager impacting this 13:29:12 ... i'm not sure if we should split this between resizing and window movement 13:29:33 q? 13:29:57 ... I am not sure how useful maximise and minimise on the window 13:31:00 whimboo: in bidi we can run any commands in any context 13:31:11 ... but there are some commands that need that context to be in focus 13:31:28 ... e.g. puppeteer needs it for screenshots 13:31:35 q+ 13:31:56 ... and browsers may throtlle what is happening in non-focused browsers like firefox does 13:32:00 ack next 13:32:45 Sam Sneddon [:gsnedders]: related to throttling, there are browsers following OS "low power modes" which can impact the frequency of different events 13:33:04 q+ 13:33:14 ... this is kinda detached to focus but has similar impacts to being in out of focus 13:33:47 whimboo: Firefox doesn't have this impact 13:34:08 mathiasbynens (IRC): Sam Sneddon [:gsnedders] should we add this to the queue? 13:34:23 Sam Sneddon [:gsnedders]: maybe but I'm not sure of the proirity here 13:34:56 whimboo: we could maybe add this a capability 13:35:31 Sam Sneddon [:gsnedders]: more importantly going into lower power mode may break websites so we want to be able to do that somewhere 13:36:31 simons: Framehandling: this boils down to getting a browsing context of a frame. Executing JS might not always work 13:36:32 ... t 13:36:59 ... the classic has commands to do this and would be good to make work 13:37:14 q+ 13:37:15 jgraham_ (IRC): in bidi you can do this via executeScript 13:37:54 ... but there might be the missing part of returning an iframe should return the context. I believe ther eis an open issue for that 13:37:54 q+ 13:37:56 ack next 13:38:16 ack next 13:38:53 Jim Evans: there is some functionality from the browsing context as that has child browsing context shared 13:39:14 simons: as long as we can formulate classic over bidi here then we should be fine 13:39:53 whimboo: clients should be able to track all of this 13:39:57 ack next 13:40:56 sadym (IRC): do we have a use case for the finding a node that could be in an child context? 13:41:30 AlexRudenko: we might have a use case in puppeteer especially around clicks but not sure 13:42:22 do we have a use case for the finding a node that is a root for the child context? 13:42:52 *specific child node 13:42:52 jgraham: a11y inspection: in classic we have getComputed{Label|role} 13:43:18 ... there are going to be more requests probably from other groups 13:43:29 ... we should at least reimplement classic over bidi here 13:43:45 mathiasbynens (IRC): there is also querying the a11y tree instead of just dumping it 13:46:04 Sam Sneddon [:gsnedders]: There are some investigations into the tree querying by other wg's and that might make it into classic at some point 13:47:03 s/that might/querying parent/child relationships might/ 13:47:36 RRSAgent (IRC): make minutes 13:48:03 rrsagent, make log public 13:48:14 rrsagent, draft minutes 13:48:15 I have made the request to generate https://www.w3.org/2023/06/14-webdriver-minutes.html gsnedders 13:49:16 s/RRSAgent (IRC): make minutes// 13:58:56 simons: Proxy settings: I can see that we are add this and delegate down to new session 13:59:21 whimboo: we don't have wdspec tests atm 14:00:17 simons: Timeouts: we have these in classic but no analogues in bidi yet 14:00:25 jgraham_ (IRC): from my point this is by design as it can be implemented in the spec 14:01:08 simons: not all languages can do this in a sane way 14:01:32 ... and then if you're going across the web might cause other issues 14:02:15 q+ 14:02:15 unknown: if the person are connecting over long distances and causing issues thats outside scope 14:02:44 simons: not everyone has good UAT systems 14:02:45 q+ 14:03:04 unknown: most languages can handle timeouts 14:03:48 simons: a lot of languages can this but then creates situation where we are not the same in all clients 14:04:02 q+ 14:04:45 simons: we can put it anywhere, in classic we put it the spec as that is where we felt the complexity live 14:05:39 q? 14:06:19 q- 14:06:43 q- 14:06:53 q- 14:07:09 whimboo: we need to make sure that for timeouts we have all the same items in classic as they have script/navigations etc timeouts 14:07:56 jrandolf has joined #webdriver 14:08:01 jgraham_ (IRC): file upload: for classic we handle input type=file and we probably need to figure out something similar for bidi 14:08:31 q+ 14:08:33 ... there also may need to handle sending the file to the remote machine to run the file upload 14:08:36 ack next 14:09:20 simons: one small note: for uploading on remote machines an intermediary node should handle that and selenium has prior art for that now 14:10:59 sadym (IRC): element location: is this for find element 14:11:56 jgraham_ (IRC): there are commands for handling the location of the element and we should probably add that to the end 14:12:11 q? 14:12:49 q+ 14:12:49 ack next 14:13:02 q- 14:14:20 whimboo: isShown: So this is an API to see if an element is visible... but this might also be shared in the atoms line 14:15:11 automatedtester: I think chromedriver uses the atoms here 14:15:13 ... and maybe safari 14:15:21 Sam Sneddon [:gsnedders]: I don't think we do 14:16:46 jgraham_ (IRC): form elements: this is specifically for setting complex form input type e.g. 14:16:56 ... and we don't ahve means to set that 14:17:05 q+ 14:17:40 ... and I am assuming puppeteer has a way 14:17:41 ack next 14:17:49 orkon: we do this via script execute and set the value property 14:18:46 mathiasbynens (IRC): there are ways to do via setting the value property and works for most things 14:18:59 ... but not work everywhere 14:19:57 jrandolf: we might be able to do things with interaction in another way 14:20:07 Sam Sneddon [:gsnedders]: these don't always work on mobile 14:20:45 s/in another way/with drag and drop/ 14:20:54 s/these don't/drag and drop doesn't/ 14:20:59 whimboo: element interaction: this covers all elements 14:21:26 ... we have most of this covered by the user interaction APIs 14:21:56 ... we probably don't want to carry over element send keys from classic 14:23:05 ... and we can remove from this discussion as it's being implemented 14:24:21 q+ 14:24:33 q- 14:24:42 jgraham_ (IRC): browser process info: the request is to have system information being sent over so that we can return PID and system usage info 14:27:02 Jim Evans: geo location: the idea that someone wants to be able to set the browser location different to where they are currently testing 14:27:14 ... e.g. testing differences between US and EU 14:27:32 ... not currently avialble in classic 14:27:59 ... and this also goes for the timezone 14:28:07 mathiasbynens (IRC): yes agreed 14:28:46 ... but this also comes to the idea of permissions for geolocation. We should set the value so the prompt doesn't appear to the user if it also ready set 14:30:17 sadym (IRC): User Agent: If we split it from device emulation then we should need to set the user agent for the given browser context 14:30:24 .. and it is required by puppeteer 14:30:53 jgraham_ (IRC): is getting different to window.navigator.useragent? 14:31:32 AlexRudenko: there can be a need for original user agent vs browsing context user agent 14:32:43 whimboo: locale/lang emulation: it is important to be able to change the locale/language so that the relevent content is sent 14:32:52 ... this is a request from the playwright team 14:33:37 jgraham_ (IRC): history traversal: This is implemented in classic for moving back/forward through pages 14:34:27 jgraham_ (IRC): user gesture during navigation: it's not gesture in the terms of input 14:35:21 AlexRudenko: in script there are reuqests to make sure scripts are available before a page load for gestures 14:35:47 https://github.com/web-platform-tests/rfcs/pull/128 14:36:02 Sam Sneddon [:gsnedders]: there are things in html for handling some of these cases 14:36:53 https://github.com/whatwg/html/pull/8609 14:37:07 q+ 14:37:23 q- 14:38:04 whimboo: screenshots; We have basic feature but don't have all of it. e.g. we dont have full screen or element screenshots 14:39:25 jgraham_ (IRC): so lets split this to element and others 14:40:34 q+ 14:40:39 q+ 14:40:46 ack next 14:41:10 q- 14:41:28 q+ 14:41:39 orkon: I wanted to mention that this could be solved by cropping images 14:42:34 ack next 14:42:54 Sam Sneddon [:gsnedders]: what happens if the element is larger than the viewport 14:43:23 automatedtester: good questions but not part of this question now :) 14:43:43 whimboo: click and wait: this is a feature for classic 14:44:25 ... if you click an element and it has potential for the page to load and capture that it is moving over 14:44:55 ... it's tricky for browsers to do this when it could handle this in the client 14:47:31 sadym (IRC): atoms: we use selenium atoms in chromedriver 14:48:16 ... do we want to be able to handle things purely in browser or do we want to allow the use of atoms for things? 14:48:18 q+ 14:48:22 q+ 14:48:25 ack next 14:48:33 q+ 14:48:52 mathiasbynens (IRC): this goes to prioritization and if we can do things simple in the client 14:49:35 ... I think we should unlock more use cases even if the way we do it isn't optimal 14:49:41 ack next 14:50:06 jgraham_ (IRC): the spec already supports this in bidi via sandbox and preloadScripts 14:50:21 ack next 14:50:51 simons: for the atoms are only needed for element displayedness (and get text on top f that) 14:51:10 ... so we can probably see if we still really need them 14:51:15 ... or a different proxy? 14:51:26 s/I think we should unlock more use cases even if the way we do it isn't optimal/imho it’s more important to unlock brand new use cases than it is to spec + implement things that can already be done in a slightly less nice way (on the client or via script evaluation)/ 14:52:57 jrandolf: keyboard layouts: the main goal is to support internationalised keyboards 14:53:01 ... I have a design doc on this on classic 14:53:18 ... the MVP description :The ability to test international keyboards 14:53:34 ... there are multiple ways to implement this moving forward 14:54:57 100% we should do something better for permissions 14:55:01 automatedtester: permissions, is this not just classic over bidi implementation 14:55:25 Sam Sneddon [:gsnedders]: there are more complex use cases to handle it 14:55:56 jgraham_ (IRC): I think we should improve the way we do it via events to know its there and then handle rather than try pre handle it 14:57:51 jrandolf: drag and drop capabilities: This is different to user interactions 14:58:43 ... there are issues between OS(win/lin). Mouse events need to handle drag and drop as you can't do it 14:59:00 ... let's add a property to know if a client can handle drag and drop 15:02:45 RRSAgent: make minutes 15:02:47 I have made the request to generate https://www.w3.org/2023/06/14-webdriver-minutes.html jgraham_ 15:04:26 Are we having the monthly meeting later? I'm guessing not, but I'm checking now 15:04:46 Yes, it's happening as normal 15:04:53 RRSAgent: bye 15:04:53 I see no action items 16:02:01 RRSAgent has joined #webdriver 16:02:01 logging to https://www.w3.org/2023/06/14-webdriver-irc 16:02:01 Yeah, I didn't remember how to end the meeting and start a new one, so it makes more sense to re-invite them 16:02:18 Zakim has joined #webdriver 16:02:24 present+ 16:02:30 present+ 16:02:44 Meeting: WebDriver June 2023 16:02:44 present+ 16:02:51 chair: David Burns 16:02:54 present+ 16:02:54 but fighting the video conf software 16:02:55 scribe: David Burns 16:02:57 present+ 16:03:04 ScribeNick: AutomatedTester 16:03:08 present+ 16:03:28 couple of mins please 16:03:34 Agenda: https://www.w3.org/wiki/WebDriver/2023-06-BiDi 16:03:56 (I'll unfortunately need to drop off at the :25 mark, just FYI) 16:04:39 present+ 16:04:42 present+ 16:04:54 jugglinmike has joined #webdriver 16:04:59 present+ jugglinmike 16:06:10 present+ 16:06:10 present+ 16:06:14 present+ 16:06:23 present+ 16:06:37 Topic: AT Driver 16:07:56 jugglinmike (IRC): Today, I am going to show off the work that I am doing around normalising the behaviour around screenreaders and hopefully the future of assistive tech 16:08:17 ... we want to make sure that we set what we believe is the behaviour that we need 16:08:51 ... and today I am will be going through the community group report 16:09:26 slides https://docs.google.com/presentation/d/1cEonR8cMkQz4WgCc6PlPypLLZdo_K2a3Z_gO167XU6s/edit 16:09:57 ... automation in this area is unnecessarily hard 16:10:07 ... and we want to simplify this for developers 16:10:23 ... and allow them to make sure they give users good user experiences 16:10:59 .... this is a protocol to introspect and remote assistive tech via a bidi protocol 16:12:02 ... so today I want to show what we have done and where we are going so we can collab 16:12:18 ... and using your knowledge of compat issues 16:13:37 ... so we are wanting to see improvements from our proposal and what would it take to get it into the BTT charter 16:14:06 ... current status (see slide 5) 16:16:02 .... (discusses what has been specified) 16:16:14 ... what we need to do next is start/stoping sessions 16:16:35 ... and so on 16:16:47 ... (discusses current implementations) 16:17:27 ... and these implementations are trying to connect to the OS 16:17:57 q? 16:19:06 ... If you're starting webdriver bidi from scratch, what would you do differently? 16:19:12 q+ 16:19:58 ack next 16:20:25 jgraham_ (IRC): I don't think that there are any large landmines here 16:21:06 ... there are some things that we would do differently but only on the 2nd review 16:21:12 ... and hindsight is good 16:22:01 ... capabilities is one area that you might want to avoid... maybe 16:22:02 q+ 16:22:05 q? 16:22:10 ack simons_ 16:22:54 simons_: I would follow jgraham_ (IRC) says generally but for capabilities see them as a config item too 16:23:10 q+ 16:23:48 ack next 16:25:07 automatedtester: just be aware of how chatty your protocol is 16:25:48 jugglinmike (IRC): for capabilities we won't need all of it 16:26:04 ... since for most cases it's mapped to 1 machine always 16:26:15 boazsender has joined #webdriver 16:26:21 q? 16:27:04 ... then if there are more questions later I will email this wg with more details 16:27:55 ... then the 2nd item is "what would it look like to promote this proposal to an editors draft in the BTT charter" 16:28:02 q+ 16:30:23 q+ 16:30:25 I think the question I have on this is the tradeoffs between a new WG and a different WG given that the degree of overlap in expertise might be quite small i.e. few people would be involved in both things 16:32:07 automatedtester: I think for this question it's mostly a process question that I and a couple others would need tow rok through. figure out if this wg is the best place or is a CG sufficient etc 16:32:09 ack next 16:32:13 ack next 16:33:12 Sam Sneddon [:gsnedders]: the current charter runs out in August 2023 so we would need to sort that 16:33:16 +1 16:33:54 ... and then for the ACs will need to check that there would be multiple implementations which seems less of a concern and understanding how the ACs will view this 16:38:13 Topic: Roadmap followup - setting priorities 16:38:53 jgraham: for those who weren't here earlier we came up with a spreadsheet https://docs.google.com/spreadsheets/d/1Cg3rifrBZClIitU3aFW_WDv64gY3ge8xPtN-HE1qzrY/edit#gid=0 16:39:12 ... and I have set a couple priorities 16:39:30 ... and my proposal goes in and assigns a priority to each feature 16:39:59 ... and this will hopefully allow us to figture out short term goals and the larger long term goals 16:40:03 q? 16:41:21 Topic: Should we default Wdspec tests to make use of HTTPS by default 16:41:33 github: https://github.com/web-platform-tests/wpt/issues/28847 16:42:06 jgraham_ (IRC): WPT in general uses http as the default. THis doesn't match the web anymore 16:42:45 ... this is not going to impact the webdriver so much 16:43:04 ... so we should move that to be more like the web 16:43:06 q+ 16:43:12 ack next 16:44:35 automatedtester: as long as we still make sure that we test misconfigured servers then I don't see this being an issue 16:44:39 jgraham: that will be fine 16:44:55 Topic: Targeting documents by ID 16:45:05 github: https://github.com/w3c/webdriver-bidi/issues/434 16:45:23 jgraham_ (IRC): in bidi we route commands to a specific browsing context 16:45:40 ... that is fine but it can cause problems and is subject to race conditions 16:46:09 ... e.g. if the page is navigating when the command is sent that it would be executed in the wrong place 16:46:45 ... in addition to target a context/navigable that you would be able to send commands to an id for a document 16:47:09 q 16:47:12 q+ 16:47:21 ... and if it couldnt go to that document that it would error instead of just going ahead 16:47:22 ack next 16:47:50 sadym (IRC): this document idea, do we want it to be used elsewhere? 16:48:10 jgraham_ (IRC): we would want to make sure that it is sent back during the serialisation 16:48:28 ... I havent thought about scoping events down to a document 16:48:50 ... or network interception down to the document 16:49:18 q+ 16:49:19 q? 16:49:24 ack next 16:50:00 simons: document IDs is a chromium idea from what I can see... is this browser agnostic ? 16:50:05 ... or can we make it that way 16:50:25 jgraham_ (IRC): we can define it for our purposes 16:51:27 q? 16:51:48 Topic: Update of key codes - wpt tests landed before spec changes 16:51:59 github: https://github.com/w3c/webdriver/pull/1740 16:52:32 jgraham_ (IRC): there is a pr on the webdriver spec 16:52:41 ... this is more a process question 16:53:21 ... so this is more of a "we shouldnt merge tests until the spec changes have been merged" 16:53:26 +q 16:53:35 ack next 16:54:16 jrandolf: I did check everywhere 16:54:45 ... and it did work everywhere but I waited a month for the merge to happen 16:55:03 +q 16:55:21 jgraham: we should have checvked it quicker 16:55:32 ack next 16:56:19 jrandolf: there are some keycodes that we saw were missing 16:56:32 ... and should match behaviour on all platforms 16:57:24 https://github.com/web-platform-tests/wpt/runs/13660763249 16:57:38 q- 16:58:23 jgraham_ (IRC): FYI: WPT not showing failures doesn't mean it has tests passing 16:59:00 +q 16:59:06 ... it has some failures. We should also see about defering if there are something there. 16:59:09 ack next 16:59:21 -q 17:01:03 jgraham: we should see if there is a better source for the keycodes than what we are currently using and see if it makes sense to use that 17:01:10 The other question about key codes is whether they vary on different OSes (for the same browser). There's a lot of historic complexity here. 17:02:14 RRSAgent: make minutes 17:02:15 I have made the request to generate https://www.w3.org/2023/06/14-webdriver-minutes.html jgraham_ 17:02:46 RRSAgent: make logs public 17:03:14 RRSAgent: bye 17:03:14 I see no action items