Hi Alf, with me, I have Max and Sadeem who is working on WebDrive protocol. And we are having a chat on that same. Hello, everyone. Welcome to my presentation about WebDriver byday. So in this session, I am going to present you the current progress with WebDriver byday. I don't expect the presentation will be actionable. Please don't worry if you don't understand some specifics of the protocol. Most likely, you as a developer are not required to implement the protocol itself. And hopefully it will be implemented by both browsers and Selenium or other testing frameworks. And let's start with my presentation. So I'm a software engineer since 2004. I started as a web developer and then transitioned to backend, full stack, front-end, SDT. And currently I'm working in Google on Chrome DevTools and specifically on WebDriver byday protocol. So you can find my details here. And, yeah. As I mentioned, the main goal of the presentation is to give the general overview of the protocol development, of the protocol development process and where we are now. So I'm going to cover these topics. It's what is byday. I'm not going to get that deep into the description of WebDriver byday. If you're curious, you can read the blog post written an year ago where we try to justify why we're working on that and what exactly it should lead with. Then I will tell you a bit about what the protocol development process looks like. It's specification, verification, implementation, and then at the end I will show some milestones, so which way we think it will go soon. So what is WebDriver byday? So there is a link to the blog post. You can read through the general overview of that, sorry, not general, but like a bit more detailed overview and many differences between WebDriver Classic and WebDriver byday and why we work on that. But I just want to say that it's a W3C standard and there are a list of organizations mostly working on that. So yeah, it's a collaboration of not only these organizations but yeah. Why do we work on WebDriver byday? So the motivation number zero is you probably was in such a situation when you wanted to test something manually and it was broken and you want to fix it again and again, so yeah. But actually Google's mission is to organize the world's information and make it universally accessible and useful. Just a quick check, looks like the slides and we are on the first slide. Just a check, okay. If you move to the second slide, yeah, I can see the slides now. Sorry, was there one slide? Yes, we were on the first slide, yeah. Sorry for that. I probably should switch here. Okay, again, my name is Maxim. As I mentioned, software engineer since 2004. I work on the Chrome automation and DevTools and specifically on the WebDriver byday. So, and here is the introduction I want to go through. The main goal of the presentation is to give a general overview of the WebDriver byday protocol development process and to give an update on the current state and at the end I'm going to show where we think it will go. And yeah, what is WebDriver byday? So, here is a link where a blog post written a year ago with the main motivation, main differences between the WebDriver classic and WebDriver byday and the main advantages of it. So, I just want to mention that it's a W3C standard and there are lots of organizations working on that. So, basically we try to figure out what shape it should have and how can we implement each of us, how we can implement the protocol. So, why do we work on the WebDriver byday? Because you probably know all of us was in the same situation, I'm quite sure. But actually, Google's mission is to organize the world's information and make it universally accessible and useful. And we care a lot about web pages having good quality, which makes automated cross-browser tests very relevant. Other browser vendors have more or less the same motivation, I'm quite sure. And let's talk about WebDriver classic versus byday. So, WebDriver classic is HTTP based and it means it has only polling model and it provides only high level control. Even though we can add additional methods to provide lower level control, all kind of emulations and so on, we still cannot fire the first issue with the polling model. So, we end up with the byday, WebDriver byday, which is a bidirectional protocol based on the WebSocket, and it allows us to use async calls and wait. And it will provide lower level control over the browser. So, let's talk first what new protocol means. So, we see the new protocol as something which is specified. There is a way to verify it and it's implemented. What does mean it's specified? Current version of the specification you can find here by this link, but I just want to give you a general feeling of what it looked like. So, you are not required to get into the details too deep. Here is an example of common script evaluate and there are steps, but the browser which wants to or any server which wants to implement the WebDriver byday server has to follow when it receives the common script evaluate. Verification, for verification we use web platform tests you can find a link here. Basically, it's a set of Python tests. There are lots of them. It's over 600 related to the WPT or to WebDriver byday. Here is a small example of the tests. It's a quite trivial one. So, you see there are lots of pairs of values and we call script evaluate. There is an expression and verify that, for example, if you evaluate and define, the return value is properly serialized to type undefined or if you send a beacon, it's serialized with beacon. So, that's a real example of one of the WPTS. Not all of them are that trivial, but still just wanted to give you a general impression of what is that. So, there is a link where you can check the current implementation state of the byday. As you see, the Chrome edge and Safari are not in leads here. So, basically, in Chromium, we implemented it in the different way so that currently Chrome driver doesn't support WebDriver byday. But we work in hardly on that and let me show how it's done. So, we have a byday CDP measure and how it used to work. We used to have Chrome driver and clients talk WebDriver classic to Chrome driver, while Chrome driver talks to Chromium via CDP, which is Chrome distools protocol. The model we now implemented is slightly different. So, the user talks to WebDriver byday via WebDriver byday to Chrome driver, which sends that byday commands to byday CDP measure and that byday CDP measure sends all the commands to Chromium and translates CDP events to the byday events and translates it to Chrome driver, which just processes to the client. So, having that, we implemented almost all the byday in byday CDP measure and currently working hard on implementing the integration of byday CDP measure into the Chrome driver. After it will be finished, you see the result should be more positive. We should be quite green there. The same goes to edge driver. We're working together with Microsoft so that the edge driver will be implemented byday as well. So, Firefox status, they working on the supporting new features in Selenium and to other WebDriver clients and they already done console local events and navigation commands and working on network events and navigation events and script execution. So, let me talk about the roadmap, how we see it. The first step was minimal scenario. Second is high-end use, which where we are now, then Google search, capital spin short, print to PDF and request interceptions. So, what we mean in minimal scenario, we wanted just to open a page, find an element and return the element intent. We didn't want to, we didn't require to get all the specification for all the steps and all the WPT tests and so on. What we wanted is just to make it work in at least two browsers. So, we made it cross-browse the script and we did achieve it. So, this minimal it with scenario, the link you can find later. It can be run against both Chromium by the ICTP map and against Firefox. So, voila, we've done with that. The second milestone we see is high-end use, we are working hard on implementing now. So, for this milestone, it's basically the previous scenario when we open the page, get some content and return to the user. But we want to have all the free parts here, specification, WPT tests and implementation. So, the component there you see it's creating, navigating browser context and making some calls in the script so that they get content of the high-end use page. So, the next milestone we are facing is we call it Google search. So, in this milestone, we are going to focus on the emulation of the inputs. So, it's a keyboard input and mouse input and another step is element selection. I have to underline that this is what we want to, that is our priority. But it can be changed over time. For example, there is a chance that element selection can be placed with the script call function. But yeah, please stay tuned on that. The next milestone we want to achieve is capturing a screenshot. So, the scenario is quite simple. We load the page and we capture the screenshot. And after that, we want to make a print to PDF. So, we load the page and we print to PDF the whole page. You can do it currently in PPTS, so we want to have it to be enabled to print PDF in all the browsers, whatever you automate. And the last but not least, it's network request interception. We want to set up some network interceptors and then load a page with all the pictures replaced with docs. Yes, I like docs. So, that's the most motivating part of all the work for me. So, we want to make this look like this. Isn't it cute? So, that's actually all I wanted to walk through. Please ask me any questions if you have. Yes. I see two questions. Okay. For now, let me read that out. It's questions from Badi Sharan. He asks, how similar or how different it is from Playwright's DevTools protocol? It's a good question. I'm not aware of Playwright's DevTools protocol. For what I know, Playwright uses CTP as well, Chrome DevTools protocol, so we use the same protocol. Okay. But if we talk about how it's different from Playwright, it's, well, we develop the new protocol underneath, so any testing framework, Playwright, Selenium, Preputier, anyone can use the very same protocol in all the browsers. Yes. So, I have another question from Mudit. So, the question is, what is the difference between CTP and Badi? Yes, a lot for the question. Unfortunately, there is no short answer to the question. I would, at first, I would recommend you to read the blog post I mentioned. But the short answer is, the CTP is very Chrome-specific, so as long as it was developed for Chromium, it's very DevTools-specific, I would say. So, it has lots of specific things for DevTools, which doesn't make any sense to implement in all the browsers. So, from that perspective, CTP and Badi, they are not twins, they are siblings. So, we got some ideas from CTP, which does work, but we had to add additional things like serialization, for example. Because in CTP, currently, you can only make JSON or not JSON. Basically, it's mostly JSON serializable values. So, we have one more question from Nishant. So, Nishant. So, yeah, I think that's done. So, the next question is from Prem Raj. What makes the difference introducing BidiMapper, introducing between Chromium and ChromeDriver? So, let me read it as that. What makes the difference introducing BidiMapper, introducing between Chromium and ChromeDriver? As I understand, the question is, why do we introduce the BidiMapper at all? So, the main reason is we didn't want to overcomplicate the ChromeDriver. And we wanted to make the Bidi, as long as Bidi is currently quite... It's still developing. We want to keep a flexibility there and not to add it to the complexity to the ChromeDriver. So, basically, we added the new layer to encapsulate all the Bidi logic and keep them separate and keep more flexibility in both the driver classic and the driver Bidi. So, one more question. When is it planned for release? That's a tough question. I don't have any dates for now. We're working hard on that. As I mentioned, probably it will... I would be quite pessimistic. Sorry, if I... I don't think it will happen in this year, at least a bit, but you already can try to use it. So, it's fully... The minimal scenario is fully implemented by Firefox and you can use the basic scenario with the BidiMapper, for example. But it's not in the ChromeDriver yet. When it will be implemented in ChromeDriver, the basic... Well, it will be... Probably it will be in Q3. ChromeDriver will support Bidi when it will be useful end-to-end, probably next year. Okay. This is from Sudhendra. So, I had this question. What changes would be needed in our code using Bidi whenever a browser is upgraded? Ideally, you don't need any changes in the Bidi. Well, again, Bidi is protocol, so we don't... We do want to keep the protocol the same and implementation agnostic. Meaning, theoretically, you don't have to do anything and keep the user the very same protocol, even if you upgrade your browser or switch browser and use... To test the very same code, use the very same code to test each page in Safari, Chromium and Firefox. So, from that perspective, you are not expected to change anything. Another question, what changes will you need to start using Bidi, but I guess it wasn't a question. There's another question, okay, which asks, with Bidi, will test execution speed comes down or goes up? It will be faster because you have not pulled the asynchronous model, so we expect it will be way faster. So, for us, our early measurement showed about 20% speed improvement. Probably because of the... You don't have to wait, pull several times the events, it will be sent you immediately. Okay. So, the other question, which I am seeing is, is Bidi considering a video recording of the viewport? It probably will be there. I am not sure yet and we don't have a specific work done for that yet. Okay. I have a question now, Maxine. Is it a replacement for the classic driver? In the long-term scene, yes, we expect WebDriver Bidi to be able to replace WebDriver Classic. We don't, but we don't plan to stop supporting WebDriver Classic. Okay. So, what is that one major advantage, okay, which is seen to consider this Bidi and not... Lock events. That is not easy to lock events in WebDriver Classic and there is a really easy way one comment in the WebDriver Bidi. Okay. So, the common question, okay, with engineers who are writing automation, will there be the need to change the automation code when we start using the Bidi and not the Classic? Well, theoretically it should be seamless for you, so you should just... We don't expect you to realize it, but again, it's up to the testing library you use, so it's up to the implementation of the client you use. So, if you use Selenium, for example, and Selenium start using Bidi instead of Classic, you shouldn't recognize that, but you will probably provide the new APIs and new possibilities which you can use. But it's... We expect it will be backward compatible. Thank you, Maxim. Thanks, everyone.