07:57:47 RRSAgent has joined #webdriver 07:57:47 logging to https://www.w3.org/2022/08/24-webdriver-irc 07:57:47 jfernandez has left #webdriver 07:57:54 Zakim has joined #webdriver 07:58:03 ss has joined #webdriver 07:58:28 RRSAgent: start meeting 07:58:28 I'm logging. I don't understand 'start meeting', ss. Try /msg RRSAgent help 07:58:58 RRSAgent, start 07:59:06 Meeting: Automation summit Berlin 07:59:12 Chair: David Burns 07:59:17 RRSagent, set logs world-visible 07:59:24 jfernandez has joined #webdriver 07:59:25 Scribe: David Burns 07:59:36 ScribeNick: AutomatedTester 07:59:48 hablich has joined #webdriver 08:00:04 present+ 08:00:06 RRSAgent: this is WebDriver BiDi Automation Summit Berlin 08:00:06 I'm logging. I don't understand 'this is WebDriver BiDi Automation Summit Berlin', foolip. Try /msg RRSAgent help 08:00:21 present+ 08:00:29 present+ 08:00:34 Meysam has joined #webdriver 08:00:36 present+ 08:00:39 AlexRudenko has joined #webdriver 08:00:42 present+ 08:01:02 titusfortner has joined #webdriver 08:01:35 present+ 08:02:09 thiagowfx has joined #webdriver 08:02:21 present+ 08:02:28 present+ 08:02:46 present+ 08:03:06 present+ 08:03:18 present+ 08:03:23 present+ 08:03:25 present+ 08:04:43 Agenda: https://www.w3.org/wiki/WebDriver#Meetings 08:05:02 Agenda: https://www.w3.org/wiki/WebDriver/2022-08-BiDi-Automation-Summit-Berlin 08:05:22 present+ 08:05:32 present+ 08:05:34 present+ 08:07:23 I am impressed at the number of people in this room who feel safe to not have their laptops plugged in.... 08:08:16 jdescottes has joined #webdriver 08:09:19 Who's scribing? 08:10:31 I am when we start officially 08:11:59 Anybody a link to the Edge roadmap? 08:12:01 I'd love to see the Edge Bidi roadmap 08:12:51 Maybe it was posted in the Zoom call? can somebody share it here too? 08:13:01 everything is linked here: https://www.w3.org/wiki/WebDriver/2022-08-BiDi-Automation-Summit-Berlin 08:13:05 thanks 08:15:02 mathiasbynens (IRC): These slides show the road map that Chrome see ... and to start a discussion 08:15:30 ... THere are a group of users from implementators to end users 08:16:32 Slides: https://docs.google.com/presentation/d/18SJv0K1_yeF9h6Gg42El-iMtL3uGiZRYgqmrScCqCuE/edit#slide=id.p 08:16:49 ... and here is the WPT.fyi page to show that things are moving forward 08:17:16 ... but we need to make sure that this group has alignm,ent to make sure that users are put forward 08:17:26 (those slides aren't currently public) 08:17:26 This is https://github.com/GoogleChromeLabs/chromium-bidi/milestones?direction=asc&sort=title&state=open 08:17:31 ... here is the chrome milestones 08:17:46 ... and here is our roadmap 08:18:26 ... [talks through slide "Chrome's Current Roadmap"] 08:18:50 ... this is based off the Puppeteer use cases 08:19:32 Slides are public now, oopsie 08:19:33 ... We don't see this as full roadmap or the order we think everyone should work on 08:19:43 q+ 08:19:56 ... what about the other items? 08:20:11 q? 08:20:37 ack simonstewart 08:21:05 q+ 08:21:23 simonstewart: step 7 in your roadmap would be to reformulate webdriver http on this... 08:21:35 mathiasbynens (IRC): is that a goal 08:21:46 simonstewart (IRC): yes that has always been a goal 08:22:07 It should be possible to do everything from webdriver classic in webdriver bidi 08:22:40 Sam Sneddon [:gsnedders]: webdriver classic implementations are built to similar things that are in CDP 08:22:53 q? 08:23:01 ack foolip 08:23:03 slides link: https://docs.google.com/presentation/d/18SJv0K1_yeF9h6Gg42El-iMtL3uGiZRYgqmrScCqCuE/edit 08:23:09 Thank you 08:23:54 foolip (IRC): do we want to rewrite the spec or are we wanting to copy behaviour. 08:24:19 simonstewart (IRC): I don't think we want to rewrite the spec but we want to make sure we have the same behavior 08:24:39 q+ 08:24:49 q- 08:25:09 whimboo: we are missing a lot of tests in the webdriver classi which makes things harder to make sure we have the same behaviours 08:25:15 q? 08:26:22 https://docs.google.com/document/d/1azpI_HHYDew5UzB_r-b9J-OsWRAP1E3g2bstAPs7yF8/edit?pli=1#heading=h.yplbn92py38w. 08:26:53 Natasha: I wanted to introduce myself, I work on devtools and automation 08:27:05 ... this the doc that Brandon did 08:27:59 ... The first part is integrate with Bidi into Edge 08:29:50 ... after building something things Brandon added that we should do a refactor for EdgeDriver over Bidi 08:30:09 ... and how this will impact future tests 08:30:13 q? 08:30:22 q+ 08:30:25 q+ 08:30:34 q? 08:30:43 ack foolip 08:31:09 foolip: have you given more thought on how you will ship bidi? 08:32:08 that was me first, then hablich 08:32:14 I was talking, I am in the off 08:32:39 q? 08:32:47 ack Sam Sneddon [:gsnedders] 08:32:51 q? 08:33:17 q+ 08:33:40 Sam Sneddon [:gsnedders]: THere is nothing in there that is specific to edge in this code? 08:33:52 q+ 08:34:29 Natasha: There is no deviation from Chromium to Edge 08:34:46 q? 08:35:01 ack Sam Sneddon [:gsnedders] 08:35:16 ack me 08:35:29 ack Hablich 08:36:24 hablich (IRC): I have question around perf metrics. Is there an attempt to make this cross browser or is there more introspection 08:36:46 q? 08:37:24 ack 08:37:52 ack next 08:38:29 sadym (IRC): are the priorities in the doc in order? 08:38:50 Natasha: yes but 2 is the most important part to this group 08:39:19 q+ 08:39:30 sadym (IRC): what was the process on how Brandon created this list? 08:39:43 Natasha: great question, I will get Brandon to respond 08:39:58 ack next 08:41:54 Firefox status: https://wiki.mozilla.org/WebDriver/RemoteProtocol/WebDriver_BiDi 08:41:57 whimboo: I don't have fancy lides to share 08:42:14 ... I have just shared where we are so far 08:42:54 ... we have been implementing what users have wanted 08:43:07 ... [discusses a few items in the doc] 08:43:20 ... the next milestone is working on Network Interception 08:43:48 q+ 08:44:21 ... we don't have anything further planned as we are waiting for the outcome of this meeting 08:44:42 ack next 08:45:25 foolip: my question is about network events ? Do you think webdriver bidi should have how to implement a HAR? 08:45:55 whimboo: good question, we have only done the network interception. It's a big question 08:46:06 ... and we're collecting the events only 08:46:22 q? 08:46:26 Looks like https://github.com/w3c/webdriver-bidi/issues/196 is the spec change that is needed for this. 08:48:19 Sam Sneddon [:gsnedders]: For Safari, Apple does not comment on future products and releases 08:48:49 q+ 08:48:57 ack next 08:49:32 diemol (IRC): is there anyway to get help to Safari from the Selenium project? Like asking Igalia to help? 08:50:47 Sam Sneddon [:gsnedders]: I am not sure I am the right person to answer. There are 2 potential questions that needs answer do we need to have a protocol along side or on top of protocols will impact how we do things in webkit to safari 08:51:22 AutomatedTester: If Apple would like support from the Selenium project or other would like support do let us know 08:52:36 Christian Bromann: I am currently working on wdio and the next release will have this in it 08:52:49 gsnedders: What was slide 2? Or 1? 08:53:09 ... I am hoping to get the cddl package from Saucelabs so we can autogenerate things better on the fly 08:53:10 q+ 08:53:16 ack next 08:53:18 https://www.npmjs.com/package/webdriver/v/8.0.0-alpha.249 08:53:22 gsnedders: :D 08:53:33 whimboo: which commands does it implement? 08:53:39 gsnedders: missed opportunity to make slide 1 say "One more thing…" with slide 2 being the punchline 08:54:02 Christian Bromann: you send and receive objects only at the moment 08:54:17 ... it does the lowest level comms 08:54:27 q? 08:54:38 q+ 08:54:53 ack next 08:55:29 foolip (IRC): are you trying to support webdriver "classic" users or are you going be having a bidi mode 08:56:30 Christian Bromann: the transport layer won't be visibile to the user. As features get added they will slowly move over to the other users 08:56:32 RRSAgent, make minutes 08:56:32 I have made the request to generate https://www.w3.org/2022/08/24-webdriver-minutes.html gsnedders 08:57:02 simonstewart (IRC): This is likely how the Selenium client is also going to do it 08:57:04 RRSAgent, make minutes public 08:57:04 I'm logging. I don't understand 'make minutes public', gsnedders. Try /msg RRSAgent help 08:57:15 RRSAgent, set minutes public 08:57:15 I'm logging. I don't understand 'set minutes public', gsnedders. Try /msg RRSAgent help 08:57:35 RRSAgent, make logs public 08:57:43 q? 08:57:56 q+ 08:58:02 ack next 08:59:22 Puja Jagani: THis is what we have currently written and moving things forward 08:59:26 Link to Puja's doc https://docs.google.com/document/d/1dCd8Y2PYaR5mOGSmNTwllEHNmFqegfoGkP-TCKvPzSU/edit?usp=sharing 09:00:03 ... this has come from the discussions with Mozilla 09:00:28 ... the first implementation was done by Alex (p0deje) from the selenium project 09:00:36 ... and we're working on Java next 09:01:26 ... [describes handshake] 09:02:33 i/Apple does not comment/gsnedders sharing https://matrix.org/_matrix/media/r0/download/mozilla.org/774c24c6adccccd812b410301c19d3eedf64a92c/Untitled%202.001.png 09:02:49 ... [describes event handling API at a high level] 09:02:51 RRSAgent, make minutes 09:02:51 I have made the request to generate https://www.w3.org/2022/08/24-webdriver-minutes.html gsnedders 09:03:15 ... this document is a living doc as we move forward through things 09:03:44 ... I know there is some discussion about supporting CDP and BIDI in the future 09:03:57 s/Sam Sneddon [:gsnedders]/gsnedders/g 09:04:10 ... and this is our starting point 09:04:13 q+ 09:04:18 q+ 09:04:42 q? 09:04:48 ack next 09:05:10 titusfortner (IRC): I haven't read the doc as much as I would have liked to 09:05:52 ... I am not sure if this is in the doc using `execute_cdp_command` 09:06:34 ... and we don't want people using that 09:07:39 ... and we need to keep plans for what we do and have plan for docs 09:07:48 q+ 09:08:36 Puja Jagani: we have always told people not to use CDP rawly (is this a word?) but this is more about the public APIs 09:08:56 ... it's covered but I will add more specific prose in my doc for that 09:09:02 q? 09:09:10 ack hablich (IRC) 09:10:11 hablich (IRC): for puppeteer we plan to move things to bidi unless we need to have a specific item in cdp 09:11:02 titusfortner (IRC): my issue is that there are docs on other sites using low level APIs when it's not the right way 09:11:18 q? 09:11:23 ack next 09:12:20 ack next 09:12:45 simonstewart (IRC): historical note: back in the day we did only http 09:13:02 ... then we added execute cdp and never got anything back 09:13:18 ... and then we moved on to how we do CDP 09:13:30 ... Network Intercept was one of the more popular ones 09:14:22 ... and Selenium could deprecate and remove the `execute_cdp_command` as there are much better ways to do it 09:15:09 foolip (IRC): we are going to have an interesting time ahead as clients will have to do feature detection and then go from there 09:15:40 simonstewart (IRC): it's fun times ahead... we could use exception handling as flow control 🤮 09:16:06 ... we have prior art in the client on how to do that 09:16:36 q? 09:17:06 https://docs.google.com/presentation/d/18SJv0K1_yeF9h6Gg42El-iMtL3uGiZRYgqmrScCqCuE/edit#slide=id.g146bd9eddb0_1_23 09:17:44 Alex Rudenko: I work on Puppeteer at Chrome 09:18:24 ... we are going to adding bidi alongside with cdp 09:18:41 ... [discusses code example] 09:20:31 ... we are going to keep the client API the same as much as possible 09:21:41 q? 09:21:48 q+ 09:21:58 ack whimboo 09:22:40 whimboo: Will you use Bidi directly or have upgrade session process? 09:22:48 Alex Rudenko: not sure 09:23:22 sadym (IRC): we haven't settled on how we are going to be doing that 09:24:22 Alex Rudenko: we will try support everything as we move forward 09:24:24 q+ 09:24:32 ack next 09:25:07 foolip (IRC): do you have anything in particular with how the session is done? 09:25:50 whimboo: currently we have the drivers from classic to get things into the correct state and then get the connection 09:26:09 q+ 09:26:44 Alex Rudenko: we aren't sure how this will be in the spec like do we start the browser and then send capabilities... 09:27:10 whimboo: there are some PRs from jgraham that hopefully solves this 09:27:16 ack next 09:28:11 simonstewart (IRC): we need to think about how people use scalable selenium systems like our SaaS providers (BrowserStack, Sauce, et al) and Selenium grid 09:28:49 ... we need to have a standardised way to make all the permutations on clients easier to update 09:29:09 foolip (IRC): [missed question] 09:29:51 simonstewart (IRC): [describes running things locally with chrome and then moving to a grid to scale up] 09:30:20 Alex Rudenko: [describes 2 ways to start sessions in Puppeteer] 09:30:49 A consistent mechanism for starting a session means that local ends don't need to adopt a lot of additional complexity 09:32:12
09:32:39 s/[missing question]/if anything needs to change to support what Simon asked for, if we're not talking about the hub/grid URLs that you can connect to, and then upgrade to BiDi./ 09:32:49 RRSAgent (IRC): make minutes 09:33:01 rrsagent: make minutes 09:33:01 I have made the request to generate https://www.w3.org/2022/08/24-webdriver-minutes.html AutomatedTester 09:46:50 For people locally at the wework: Please ping me via mail in case you want attend today's dinner! 09:49:17 Topic: WebDriver BiDi adoption by Selenium 09:51:08 sadym (IRC): I want to see how we can move these things forward 09:51:30 ... what are the missing missing parts, collab process and priority of use cases 09:51:46 sadym (IRC): missing parts? 09:52:51 Titusfortner: We have connection starts but that's it 09:52:51 q+ 09:53:03 Puja Jagani: that is correct. 09:53:33 Titusfortner: We have logging which is purely specific to Firefox 09:54:02 ... but I see that Edge has some of that from the roadmaps 09:54:09 ... at the moment everything is missing except logging 09:54:37 sadym (IRC): what is required to get adoption? 09:55:00 diemol has joined #webdriver 09:55:02 q+ 09:55:33 titusfortner has joined #webdriver 09:55:39 q+ 09:55:55 Puja Jagani: The roadmaps give us a direction but it would be good to know what is being impl,mented by each group as we move forward 09:56:00 ack next 09:56:08 q- 09:56:17 ack next 09:56:51 whimboo: There are 2 points: 1 ) we currently see support for firefox, it would be good to add the same for Chrome 09:57:21 ... and future APIs, navigation and script execution are next and nearly complete 09:57:26 q? 09:57:57 Puja Jagani: we only did Firefox because that's the only one that we know had that features ready 09:58:07 q+ 09:58:26 ... we are going to need to do that for CHrome and then having a mechanism to send the info to Selenium TLC group for next steps 09:58:27 q+ 09:59:02 ... as things are implemented we need to have a way to know what and when things are ready 09:59:05 q? 09:59:10 ack next 09:59:44 diemol (IRC): for me it's really hard to understand the use cases for the spec 10:00:17 ... do we have a list of use cases that we can then track against 10:00:54 mathiasbynens (IRC): I'm not sure it exists but that's how we have approached it for Chrome 10:01:12 ... but it would good to track them 10:01:13 q+ 10:01:29 simonstewart (IRC): There used to be a doc/issue that had this but I can't find it 10:01:30 q? 10:01:57 https://github.com/w3c/webdriver-bidi/blob/master/explainer.md#goals 10:02:21 [various discussion about where we originally had goals recorded, trying to find it] 10:02:23 simonstewart (IRC): the link shared has a link to the goals 10:02:55 mathiasbynens (IRC): It looks like we have diverged from what we wanted and what we have implemented 10:03:21 simonstewart (IRC): [discusses items in the list at high level] 10:03:42 ... I don't think we have diverged too far 10:04:23 ... the item that's not in there are devtools support [did not catch the rest] 10:04:27 q? 10:05:14 diemol (IRC): I am trying to follow the spec and since I don't fully understand it... 10:05:46 ... is there a way we can have this in a way that maps user cases to prose changes 10:06:14 ... I think this will allow client implementors to follow 10:06:34 hablich (IRC): from a list of use cases to what is implemented? 10:06:57 [various of how use cases could be written] 10:07:19 diemol (IRC): like we have the original plans from 2019 but no way of knowing where we are on that list 10:07:40 ... it would be good to make sure we can track it 10:07:52 hablich (IRC): I can see this being useful for Selenium 10:08:12 ... are there others that could benefit 10:08:46 Christian Bromann: I've been following but it's a lot work to follow 10:09:03 https://wpt.fyi/results/webdriver/tests/bidi?label=experimental&label=master&aligned&q=webdriver 10:10:00 mathiasbynens (IRC): we have the wpt.fyi 10:11:56 q+ 10:12:00 ... it's good to track things across browsers 10:12:54 AutomatedTester: Does wpt.fyi have sufficient linking to use cases for non-browser folks to understand 10:13:22 diemol (IRC): it would be good to have something in the spec to help us 10:13:37 q? 10:13:39 mathiasbynens (IRC): I think we can use features in bikeshed to help do this 10:14:26 diemol (IRC): It would be good to help end users know what is possible 10:16:17 titusfortner (IRC): it would be good to see how end users know things in selenium/puppeteer terms 10:17:10 Sam Sneddon [:gsnedders]: another way to do this is to have the explainer linked to the parts of the spec that supports that feature 10:17:45 https://github.com/GoogleChromeLabs/chromium-bidi/milestone/2 10:18:03 sadym (IRC): here is a link to our milestone 2 10:18:42 ... in the milestone we show the command that people need to complete this tasks 10:18:54 ... and we have links to the relevant WPT 10:19:49 ... and we also have items for how far other implementors are 10:20:24 ... and it has a link to a example script 10:21:02 https://github.com/GoogleChromeLabs/chromium-bidi/blob/main/examples/cross-browser-simplified.py 10:21:38 mathiasbynens (IRC): we can see about moving some of these use cases from the Chrome repo to the W3C to help people understand where things are 10:22:24 sadym (IRC): [discusses python example linked above] 10:22:57 q? 10:23:19 sadym (IRC): we'd be happy to move share this in a wider context 10:23:25 q? 10:23:46 q-\ 10:23:51 q- 10:24:35 hablich (IRC): Assuming browsers are going to implement it super fast for Selenium to catch up? 10:24:43 simonstewart (IRC): it depends on the binding 10:30:24 AutomatedTester: [desribe issues with async/sync puthon ] 10:30:55 diemol (IRC): we want to release things as soon as possible but we want to release in tandom 10:30:57 q? 10:31:03 ack next 10:31:10 ack next 10:32:18 foolip (IRC): we need to link and make that better but a lot of the work that has been fulfilled is purely scaffolding 10:33:06 ... it would be also good to help get things prioritised 10:36:02 simonstewart has joined #webdriver 10:52:48 simonstewart has joined #webdriver 11:32:32 hablich has joined #webdriver 11:33:13 simonstewart has joined #webdriver 11:34:37 present+ 11:35:08 jdescottes has joined #webdriver 11:35:37 present+ 11:35:39 Topic: Prioritising Use Cases 11:36:34 q+ 11:38:12 q- 11:38:44 https://www.w3.org/wiki/WebDriver/2022-08-BiDi-Automation-Summit-Berlin#Agenda updated by simonstewart 11:38:57 q+ 11:39:48 simonstewart (IRC): This list is the thing that I think a lot of people are already expected 11:40:00 diemol has joined #webdriver 11:40:05 q+ 11:41:13 simonstewart (IRC): I think things like DOM events is already there 11:41:52 Alex Rudenko: allows you to install a listens and then go from there 11:42:16 simonstewart (IRC): to us that is "bootstrapping" as it allows you install a script and do things 11:42:50 foolip: [discusses bootstrapping in sandboxing with sadym] 11:43:14 simonstewart (IRC): you probably want those bootstrapped scripts to run before a page is loaded 11:43:34 ... bootstrapping, dom events and logging is the main 3 for selenium 11:43:44 ... video recording is handled out of band 11:43:55 q? 11:45:00 Request interception is also a high priority item for Selenium users 11:45:03 ack next 11:45:47 Christian Bromann: I would allow us to implement listeners so we can compete properly against tools like cypress 11:46:12 foolip: is bootstrapping worth it in or out of sandbox 11:46:21 simonstewart (IRC): what does a sandbox mean here? 11:46:22 q+ 11:46:42 sadym: [unaudible] 11:47:00 ack next 11:47:26 diemol (IRC): one of the highest priorities from Selenium is "Network interception" 11:47:27 Sandbox in this case is the JS execution context 11:47:56 ... this is the most requested and hardest to use 11:48:04 ... from Selenium that is the highest 11:48:34 ... we do get a lot of people asking for video recording and, as simon saidm we offer that in docker containers 11:48:46 ... but people want that in the borwser 11:49:04 q? 11:49:12 ack next 11:49:15 q+ 11:49:16 q- 11:49:18 q+ 11:49:20 ack next 11:49:47 q+ 11:49:54 q- 11:50:10 q+ 11:50:13 whimboo: we need to see about getting network logging done first and then we need to work on the interception next 11:50:21 ... jgraham has a PR for this already 11:50:23 James's PR is https://github.com/w3c/webdriver-bidi/pull/204 11:50:38 q? 11:50:45 ack next 11:51:00 simonstewart (IRC): do we want events and interception as 2 different groups of work 11:52:09 ... [describes immutability and mutability of these events] 11:52:55 q- 11:53:23 ... [describes how it workswith Alex Rudenko in modules] 11:53:43 whimboo: we need to start somewhere and we're starting with event logging of network events 11:53:47 ack next 11:55:11 sadym: how would we impl.ement this in the clients? 11:55:28 simonstewart (IRC): local ends already paper over the cracks between implementation 11:55:30 q+ 11:55:46 ... we can try cdp and fail and try bidi 11:55:52 q? 11:55:56 ack next 11:56:52 sadym: what about clients that do cdp but not classic they wouldn't necessarily be able to do it 11:57:24 q+ 11:58:55 ... if we deprioritise classic items then it will take non selenium clients longer to move across 11:59:27 The Actions API is https://w3c.github.io/webdriver/#actions 12:00:47 James's PR for an input module is https://github.com/w3c/webdriver-bidi/pull/175 12:00:54 scribe foolip 12:01:03 RRSAgent: scripe foolip 12:01:03 I'm logging. I don't understand 'scripe foolip', foolip. Try /msg RRSAgent help 12:01:06 ScribeNick: foolip 12:01:08 q? 12:01:17 ack next 12:02:32 diemol: On the different use cases, wondering if the next topic (reformulating) is more important? Reaching out to framework implementers which aren't Selenium. They caught up with WebDriver in a year or two. Catching up with BiDi would take more time. Important to discuss if we'll have classic working over BiDi? 12:02:48 diemol: People like to use new languages, and they've capturing a good audience. WDYT? 12:03:10 q? 12:03:25 simonstewart: I'd be happy to discuss that 12:03:25 q? 12:04:19 q+ 12:04:33 q+ 12:05:05 q+ 12:05:09 foolip: In terms of the order, I think we have two things. (1) is adding new capabilities to a framework like Selenium, which leads to new things like logging and network intercept first 12:05:32 foolip: (2) is supporting new browsers in Puppeteer using BiDi, which brings along "everything" first 12:05:36 ack next 12:06:41 gsnedders: While there's a lot of benefit in having a lot of classic defined in terms of BiDi, or having everything classic be doable over BiDi, from our PoV we'd much rather see some more immediate advantage above and beyond recreating classic over a new protocol. 12:06:47 q? 12:06:51 q+ 12:06:57 ack next 12:07:01 simonstewart: So a market differentaition in the spec? 12:07:04 gsnedders: right 12:07:20 s/in the spec/of the spec/ 12:07:46 simonstewart: Talk about reformulation and migration. Is it worth having a deprecated WebDriver module that allows to execute a classic command over BiDi? And we remove things from it as we add things to BiDi? That'd solve supporting both at the same time. 12:07:59 q? 12:08:04 TamsilAmani has joined #webdriver 12:08:16 simonstewart: Is that mad from an implementation PoV? It's the opposite of the CDP escape hatch in chromedriver. 12:08:59 whimboo: The difference to chromedriver is that we implement BiDi in the browser itself. While WebDriver classic is in geckodriver. 12:09:24 whimboo: Marionette and RemoteAgent are separate components, might not be easy. 12:09:42 sadym: Same in Chrome, we have different modules for chromedriver and bidi. 12:10:10 q+ 12:10:25 q? 12:10:30 simonstewart: boils down to defining a classic command in bidi 12:10:40 q- 12:10:40 simonstewart (IRC): I presume you're imagining something like `{"url": "/session/{session id}/element/{element id}/click", "method": "POST", "body": {}}`? 12:10:42 q+ 12:10:52 foolip: think the issue is that it would amount to reimplementing the classic command, not merely adding glue code 12:11:17 Someone: one can share code 12:11:37 ack next 12:11:50 gsnedders: yes, exactly like that 12:12:12 hablich: Would we be able to deprecate the classic escape hatch ever? If not, it would be a strange situation. 12:12:54 q+ 12:13:13 hablich: We're now talking about Selenium and supporting them. And for Puppeteer we have cross-browser goals. Other frameworks too. How does this all influence our roadmap? Depends on whether we want to move CDP-based frameworks first. 12:13:31 q? 12:13:57 q+ 12:14:21 q- 12:14:23 simonstewart: How much does it matter? Selenium has a mechanism to move some functionality to BiDi. Puppeteer also has some mechanism. Do we need to move everything in classic to get started? 12:14:37 hablich: I also don't know. What about Cypress? 12:14:54 simonstewart: Cypress works in a very different way, they inject script. 12:14:59 cb: they also use CDP for some things 12:15:00 q? to ask whether someone should (soonish) look at WebDriver Classic commands and create a mapping to BiDi, so we can see where the gaps are 12:15:11 q- 12:15:11 q+ to ask whether someone should (soonish) look at WebDriver Classic commands and create a mapping to BiDi, so we can see where the gaps are 12:15:32 AutomatedTester: As a result Cypress can't navigate across origins, etc. 12:15:40 q? 12:16:23 topic: Reformulating WebDriver Classic on WebDriver BiDi 12:16:47 ack next 12:16:52 RRSAgent, make minutes 12:16:52 I have made the request to generate https://www.w3.org/2022/08/24-webdriver-minutes.html gsnedders 12:17:05 AlexRudenko: I'm not very familiar with classic. How big is the difference between classic and what's now in BiDi? Seems like the only big difference is input events. 12:17:17 simonstewart: There's also element locators. 12:17:27 AlexRudenko: We can implement those with script evaluation. 12:18:26 simonstewart: going through the spec, there's also capabilities, modifying timeouts (for script/navigation/etc.), element states (mostly doable with JS), interaction, cookies (nice to have more control) 12:18:58 simonstewart: actions API is missing, handling user prompts, screen capture and printing. 12:19:14 simonstewart: there's also the weird concept of "is the element displayed?" 12:19:55 q? 12:20:05 AlexRudenko: I know CDP capabilities quite well, and for a lot of things there's no other way than to evaluate JS. Do we need to be as granular with BiDi as in classic? 12:20:36 simonstewart: With BiDi we wanted to avoid embedding too much complexity in the framework. More things that can go wrong. 12:21:00 simonstewart: e.g. finding elements is fine, but what about Shadow DOM? 12:21:33 simonstewart: But there's nothing to stop us from starting with JS and moving to a module as needed. 12:21:55 titusfortner has joined #webdriver 12:22:06 AlexRudenko: On classic vs new use cases, if we don't have basic support, every new user of BiDi will need to use classic as well? 12:22:10 simonstewart: yes, or CDP 12:22:17 AlexRudenko: but CDP is not cross browser 12:23:00 simonstewart: Selenium has a mechanism for upgrading to BiDi. Puppeteer also, in that you could try BiDi and fall back to CDP. New frameworks, I'd be inclined to not worry about that. 12:23:02 q? 12:23:29 whimboo: We can collect the most important thing from both sides, and maybe they match. 12:23:44 ack next 12:24:31 sadym: My main concern on adopting BiDi in Puppeteer, if we can execute JS then the main things left are input, screenshots, printing. So I'd like to prioritize those, but not reformulate everything classic. 12:24:33 ack next 12:24:34 gsnedders, you wanted to ask whether someone should (soonish) look at WebDriver Classic commands and create a mapping to BiDi, so we can see where the gaps are 12:24:49 simonstewart: Input is the most important. 12:24:53 q? 12:24:54 sadym: absolutealty 12:25:17 sadym: Simon, you'd like to avoid injecting JS? 12:25:38 simonstewart: long term yes, would be nice to only need one connection to a browser. 12:26:04 AutomatedTester: we should also consider SaaS providers, injecting JS can add latency 12:26:40 AutomatedTester: For example a "get attributes" command (scribe is not familiar with this) 12:26:55 AutomatedTester: Want to avoid "inject this JS" for every single binding/language 12:27:08 AutomatedTester: large amounts of JS at least. 12:27:40 simonstewart: In a simple case it's just `document.getElementById()` but it gets more complicated. 12:28:14 simonstewart: there are even implementations in curl 12:28:16 diemol: and bash 12:28:36 q? 12:28:41 q+ 12:29:07 ack next 12:29:20 AlexRudenko: Puppeteer is of course biased, since it's JS-only. 12:29:56 AlexRudenko: It gives you some flexibility, we can wait on some things in JS, like selectors matching, next animation frame, etc. 12:30:32 AlexRudenko: But if we want Puppeteer to work on BiDi, we'll definitely need sandbox scripts, bootstrap scripts, and bindings (installing a function that if called results in a callback in the protocol) 12:31:00 AlexRudenko: Without that it'll be a challenge to use BiDi in Puppeteer. But I can see that a lot of JS could slow things down. 12:31:11 simonstewart: Those are useful features, having them would be great. 12:31:32 simonstewart: Something you might want is the ability to wait for a command to return a non-falsy value. 12:31:40 AlexRudenko: That's implemented by injecting JS now. 12:32:04 AlexRudenko: This is done by returning a Promise, can then wait for anything. 12:32:13 q? 12:32:31 AutomatedTester: that's the end of the agenda 12:34:06 foolip: what were the 3 things for Selenium? 12:34:40 diemol: (1) network interception (2) video recording (lower priority) 12:35:02 diemol: prioritizing new use cases will leave basic use cases behind. 12:35:44 whimboo: and (3) bootstrap scripts, via cb 12:36:37 cb: I'd say intercept is more important than plain network events 12:37:58 simonstewart: there's also DOM events, things like windows/documents being created, and DOM mutation 12:38:05 +q 12:38:08 I would have another topic I would like to discuss if we have time 12:38:12 q+ 12:38:41 simonstewart: a chatty protocol isn't good for testing service providers. classic is pretty good for this. 12:39:05 simonstewart: BiDi could be very chatty with network intercept etc. etc. 12:40:08 AutomatedTester: agree with simonstewart. logging all events will produce a lot of traffic going back to a single machine 12:40:20 AutomatedTester: we have logging filtering for this 12:40:22 q? 12:40:39 ack diemol (IRC) 12:41:18 diemol: on prioritizing DOM events, it's very useful, but I don't see that happening in the GitHub issues. Might be an opportunity for DevRel to share what's happening in BiDi. 12:41:36 diemol: Can avoid a blocking wait in your tests, just have a listener. 12:41:37 q? 12:41:40 ack next 12:41:45 ack next 12:42:37 q+ 12:42:41 cb: One thing I've tried to avoid is things like stale element exceptions. With the click command we try to move the element into the viewport, but that's sometimes difficult with fixed positioning. Are there things we can do to avoid stale element exceptions? 12:43:10 cb: stale element exceptions and the element not receiving a click are the two most common errors I see 12:43:25 cb: better error messages that would help us frameworks act on it would be helpful 12:43:47 cb: give framework implementers more utilities to be robust. protocol can't do everything, but can give more information. 12:44:24 simonstewart: stale element exception is for when the element is no longer connected to the DOM 12:45:12 https://w3c.github.io/webdriver/#dfn-stale-element-reference 12:45:19 ack next 12:45:20 q? 12:45:24 q+ 12:46:12 AutomatedTester: Deviating too much from what we already have can get us in trouble. 12:46:36 AutomatedTester: My concern is we need to be deliberate when we deviate, mental models might need to change. 12:46:45 ack next 12:47:22 foolip: are there spec or chromedriver bugs for these two issues? 12:47:46 cb: Don't want to point fingers, but there are various reasons that this can happen. I can't tell whose fault it is. 12:47:51 Is it a bug report like this: https://bugs.chromium.org/p/chromedriver/issues/detail?id=3944&q=stale%20element%20exception&can=2 ? 12:48:10 cb: One idea is can we move the element to the center of the viewport instead ot the top? 12:48:46 cb: Giving framworks more ability to act could be providing the ID of the element that overlays the element you tried to click. 12:48:59 simonstewart: this is https://w3c.github.io/webdriver/#dfn-element-click-intercepted 12:49:15 simonstewart: we can add data to exceptions, and we could add an element ID here 12:49:41 foolip: is there a spec issue? 12:49:45 cb: I'll take the action item. 12:50:00 ACTION: cb to write a spec issue 12:50:04 q? 12:50:12 whimboo: I have a list of 7 items now. 12:50:17 (will paste soon) 12:51:09 whimboo: from Puppeteer I have (will paste) 12:51:34 AlexRudenko: sounds right, order maybe tweak a bit. Is there something about frame tree updates? 12:51:50 whimboo: that's the browingContext.contextCreated event 12:52:02 Selenium... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/UkIvRmvJHJhHDbbUiOksQBox) 12:52:43 Selenium 12:52:43 12:52:43 * logging 12:52:43 * Boot strap scripts (add bindings) 12:52:43 * network events and interception 12:52:43 * dom events (window/document created, DOM mutation) 12:52:43 * stale elements 12:52:44 * element interactability (eg fixed elements or overlays, in view) 12:52:44 * video recording 12:52:44 12:52:44 Puppeteer 12:52:44 12:52:44 * Boot strap scripts (add bindings) 12:52:44 * Sandbox scripts 12:52:44 * input 12:52:44 * screenshot 12:52:45 * printing 12:53:01 AlexRudenko: Is there a way in BiDi to intercept a browsing context creation? 12:53:21 sadym: is this different from bootstrap scripts? 12:53:51 AlexRudenko: this is about configuring the new context before it's created 12:54:05 AlexRudenko: maybe this depends on how we define bootstrap scripts 12:55:05 foolip: this feature is where the iframe process is paused and the CDP client can do things before continuing 12:55:06 q? 12:55:10 simonstewart: what kinds of things? 12:55:17 AlexRudenko: configure request intercept, for example. 12:55:41 whimboo: is this a new feature? 12:55:50 AlexRudenko: it's new in Puppeteer, but old in CDP 12:56:07 AlexRudenko: whether this is important depends on other APIs, if other APIs are declarative. 12:56:15 simonstewart: let's add it to the list / file a new issue 12:58:02 foolip: the implication of this is other APIs need to be on the style "if this happens, do that" like the webdriver classic alert API 12:58:06 q+ 12:58:07 q? 12:58:19 ack next 12:58:39 whimboo: does this affect only events? for bidi we can subscribe to all browsing context. new iframes automatically inherit the same set of events. 12:58:51 q+ 12:58:56 whimboo: I can only see a problem when opening a new tab/window and you want some new setup that only affects that window. 12:59:41 AlexRudenko: Example of declarative API challenge: I want all of the events from all first party iframes. 13:00:17 AlexRudenko: This might be a convoluted example. 13:00:26 q? 13:01:08 q? 13:01:08 simonstewart: With network intercept, we want filters to be specified of specific requests, to reduce chattiness. 13:02:03 ack next 13:02:05 foolip: I think this is a different tradeoff than being able to stop a browsing context before it's doing anything 13:02:37 simonstewart: some back channel use cases: (1) manipulate for cookies for any domain 13:02:44 simonstewart: so this is the login use case 13:02:57 simonstewart: webdriver classic can only set cookies for the current domain 13:03:23 whimboo: the problem users have is they're not logged in, they navigate, and the page checks `navigator.webdriver` and redirect away from the login page 13:03:37 simonstewart: (2) ability to manipulate the browser cache, clearing it during a cache 13:03:45 AutomatedTester: clear the cache? 13:04:04 AutomatedTester: there are various forms of storage. bfcache? storage? 13:04:12 simonstewart: the network cache 13:04:49 foolip: is this for test reliability reasons? 13:04:53 AutomatedTester: private mode between tabs? 13:05:10 simonstewart: no, but half way through the test, clear everything, expect to have to log in again 13:05:31 q+ 13:05:39 ack next 13:05:48 AlexRudenko: Two more features 13:05:58 AlexRudenko: (1) testing browser extensions, end-to-end testing of those 13:06:05 q+ 13:06:13 AlexRudenko: (2) getting accessibility information from the browser (some support in Puppeteer) 13:06:16 q? 13:07:04 whimboo: on (1) we do that already, can switch to the "chrome" context to interact with the Firefox UI. 13:07:18 whimboo: this is also used for testing web extensions. security implications of course. 13:07:19 q+ 13:07:26 ack next 13:07:39 whimboo: (2) a11y, we haven't implemented them in Firefox, but there are two new webdriver classic end points 13:07:51 https://w3c.github.io/webdriver/#get-computed-role 13:07:55 https://w3c.github.io/webdriver/#get-computed-label 13:08:09 AutomatedTester: Bocoup are strong advocates 13:08:15 jimevans has joined #webdriver 13:08:33 q+ 13:08:41 ack next 13:09:24 AutomatedTester: Firefox has internal support. Interactions will check if element is accessible (via the a11y tree) 13:09:41 AutomatedTester: might have been removed 13:09:57 whimboo: We don't have these two endpoints implemented. 13:10:06 q? 13:10:16 ack next 13:10:44 foolip: Alex, do you mean something more advanced than the two end points 13:10:58 AlexRudenko: yes, querying the a11y tree with something like CSS selectors 13:11:25 AlexRudenko: finding an element by an a11y property 13:11:51 AOM 13:11:57 We have an issue to fetch by a11y label: https://github.com/w3c/webdriver/issues/1441 13:11:57 AutomatedTester: has AOM been implemented anywhere? 13:12:21 rrsagent, make minutes 13:12:21 I have made the request to generate https://www.w3.org/2022/08/24-webdriver-minutes.html AutomatedTester 13:12:47 https://github.com/WICG/aom 13:13:11 foolip: AOM as it was a few years ago didn't get implemented. There's now aria* properties on Element and ElementInternals, might not have to do with the a11y tree though. 13:13:51 mathiasbynens: this is probably orthogonal to querying by a11y tree. in Puppeteer we can query by a11y property. 13:14:37 foolip: so do support the Puppeteer support for the a11y selector engine, BiDi would need some additional bits? 13:14:38 q+ 13:14:39 AlexRudenko: yes. 13:14:46 here is the bocoup presentation from TPAC Lyon I think: https://bocoup.github.io/presentation-aria-and-webdriver 13:15:38 ack next 13:15:47 AutomatedTester: How do those Puppeteer APIs impact running tests? Historically enabling things like that would make run times go up a lot. 13:16:18 mathiasbynens: We went through different phases implementing this. Started with slow and wrong, but added CDP-level support to use the accessible tree. There's some overhead, but it's manageable. 13:16:51 mathiasbynens: how common is usage? I don't have numbers, but we hear from partners that it's helpful for projects where class names are randomized. 13:17:13 mathiasbynens: but the button label and accessible name do not changes as much 13:17:35 mathiasbynens: we also have a recorder in devtools, and there we use the accessible names and labels, to make the scripts more robust. 13:18:09 in CDP we added https://chromedevtools.github.io/devtools-protocol/tot/Accessibility/#method-queryAXTree to allow us to query the a11y tree, for e.g. selecting the button with the accessible label “Search” 13:18:18 q? 13:18:26 AutomatedTester: are we good on the agenda? 13:19:10 whimboo: (1) cookies manipulation (2) browser cache (3) HTTP basic auth 13:20:11 whimboo: going through the order again 13:21:03 simonstewart: I think we use network intercept in Selenium to do auth. 13:21:53 AlexRudenko: browser cache is also important for request intercept, because then you usually want the cache to be disabled. 13:21:59 simonstewart: so disabling, not clearing 13:22:22 whimboo: where does a11y fit on the prio list? 13:22:28 AlexRudenko: far down the list 13:22:48 q? 13:23:09 Updated list: 13:23:12 Selenium 13:23:12 13:23:12 * logging 13:23:12 * Boot strap scripts (add bindings) 13:23:12 * network events and interception 13:23:12 * cookie manipulation (not same domain) 13:23:12 * manage the browser cache (clearing of network, local storage) 13:23:13 * user prompts from classic / HTTP authentication (via network events) 13:23:13 * dom events (window/document created, DOM mutation) 13:23:13 * stale elements 13:23:13 * element interactability (eg fixed elements or overlays, in view) 13:23:13 * video recording 13:23:13 13:23:14 Puppeteer 13:23:14 13:23:14 * Boot strap scripts (add bindings) 13:23:14 * Sandbox scripts 13:23:14 * network events and interception 13:23:14 * input 13:23:14 * screenshot 13:23:14 * printing 13:25:06 whimboo: intersection of these lists are bootstrap scripts, network intercept 13:25:52 q? 13:27:25 AutomatedTester: now taking a break, 15 mins 13:27:50 simonstewart has joined #webdriver 13:44:20 diemol has joined #webdriver 13:44:46 simonstewart has joined #webdriver 13:47:06 simonstewart has joined #webdriver 13:48:10 hablich has joined #webdriver 13:49:06 present+ 13:50:06 q+ how do we go from this inofficial priotization list to something more official? in particular to get also people to be able to participate asynchronously 13:51:25 q+ 13:51:26 q+ 13:51:35 hablich: now that we have rough prio, how do we get to something with broader buy-in, for people who aren't attending right now to also weigh in? 13:52:08 q? 13:52:15 AutomatedTester: I would suggest we post the list to the mailing list and say this is the list, please let us know if you have issues. 13:52:22 q+ 13:52:30 ack next 13:52:36 simonstewart: I'm fine with that 13:52:37 ack next 13:52:52 sadym: what about a PR in the GitHub repo and discuss there? 13:52:59 q+ 13:53:00 AutomatedTester: that would also work 13:53:06 q+ 13:53:14 ack next 13:54:07 q+ 13:54:13 mathiasbynens: This list of priorities is great. There are two views into any list which are (1) what's missing from the spec and (2) end-user scenarios. Seems like people are open to milestones expressed as end-user scenarios. Can we commit to doing this? 13:54:41 q+ 13:54:52 q- 13:54:52 AutomatedTester: I'll take silence as a tacit yet. 13:55:07 s/yet/yes/ 13:55:24 whimboo: I want to second this. We have a list of APIs, can create scenarios/examples for bootstrap scripts and network intercept, for example. 13:55:49 mathiasbynens: So use the list and for each give an example? Other option would be an end-user scenario that might cover multiple. 13:56:04 q? 13:56:25 mathiasbynens: If people are open to it, we can propose a list of scenarios, for folks to review. 13:56:31 q- 13:56:39 AutomatedTester: brilliant idea, action item for mathiasbynens 13:56:52 whimboo: I also like the steps you have for each milestone, pretty helpful 13:57:15 AutomatedTester: anything the WG can do to simplify the lives of people who don't work on browsers, I'll be wholeheartedly in favor of 13:57:40 mathiasbynens: yes, but to be clear it's not just about improving communication, but also for our own clarity, agreement within this group. 13:57:46 ack next 13:58:04 ack next 13:58:31 whimboo: What should we do with the other items we have? Should we define milestones for them as well? 13:58:44 sadym: We can, but deprioritize 13:58:59 simonstewart: my preference would be define top 3, and when one is done, add another 13:59:32 mathiasbynens: a rolling window approach 13:59:45 whimboo: we all have different implementation speeds 14:00:02 q? 14:00:24 diemol: what I mentioned before might apply to all browsers, if there's something we can do to speed up implementation, we can look into that 14:01:17 AutomatedTester: So let's define a top 3, as issues. 14:02:16 AI(mathias): file GitHub issue with proposed e2e milestones 14:02:19 mathiasbynens: exact implementation aside, what matters is that the information is there. 14:02:33 q? 14:02:47 Topic: TPAC 14:03:32 AutomatedTester: I'll be happy to chair remotely. I'll get an agenda page up where we can narrow down agenda. 14:04:49 gsnedders: we have 2 days for BTT 14:05:28 Action: David to create agenda 14:05:35 Topic: Autumn/Winter F2F 14:05:55 q+ 14:06:40 ack next 14:07:30 hablich: we'd be looking to organize either in Berlin in Munich, hosting at a Google office. 14:07:58 s/in Munich/or Munich/ 14:08:22 AutomatedTester: For time, North Americans probably don't want to travel on Halloween etc. 14:08:30 q+ 14:08:32 AutomatedTester: Maybe late Oct/Nov timeframe 14:09:03 q+ mid November is also BlinkOn, where I guess Chromium people want to attend 14:09:24 [super dense discussion about when thanksgivings are] 14:10:21 There's also BlinkOn to consider 14:10:45 https://groups.google.com/a/chromium.org/g/blink-dev/c/16LQXKmAD4s/m/MH9AqBD2AAAJ 14:10:51 November 15-17, 2022 14:11:34 There's also the WebKit Contributors Meeting to consider, not that I know if we've actually announced anything yet… but that's trying to arrange things to not clash with BlinkOn for the sake of Igalia people involved in both. 14:12:20 Thanks for the link to BlinkOn. I couldn't find it for the life of me! 14:12:45 AutomatedTester: wrapping up for today. thanks foolip for scribing. I'll share meeting minutes on the mailing list 14:13:04 AutomatedTester: thanks all 14:13:09 all: thanks David 14:13:20 rrsagent, make minutes 14:13:20 I have made the request to generate https://www.w3.org/2022/08/24-webdriver-minutes.html AutomatedTester 14:14:33 rrsagent, leave us 14:14:33 I see 2 open action items saved in https://www.w3.org/2022/08/24-webdriver-actions.rdf : 14:14:33 ACTION: cb to write a spec issue [1] 14:14:33 recorded in https://www.w3.org/2022/08/24-webdriver-irc#T12-50-00 14:14:33 ACTION: David to create agenda [2] 14:14:33 recorded in https://www.w3.org/2022/08/24-webdriver-irc#T14-05-28