 Yes, so, welcome to Selenium Conference, it's great to be back here in India. This is a photo from the last, the first Selenium conference we had here in Bangalore with a bunch of people. Nirash is looking particularly happy there because this was at the very end and he could relax. So yes, we've got Julian back as well, it's going to be a lot of fun. Like Nirash said, I am going to attempt to keep to time today. Last time I was here wasn't my finest moment up on stage, but hey, these things happen and it's going to be an awful lot of fun, I think, yes? Okay, are we all excited to be here by the way? I mean it's fine if you're not so long as you've paid for your ticket. Okay, so some history on the Selenium project. Many, many moons ago, almost 11 years ago now, Jason Huggins was working on the time expenses at ThoughtWorks. Now ThoughtWorks is an IT consultancy, what they need is they need their consultants to book their time and say, I was spending this many hours on this project, this many hours on this project and I spent a million pounds on phone apps or whatever it means. ThoughtWorks are also iconoclasts. They like to do things in their own way and when they were told that they had to use Internet Explorer to put in their time and expenses, of course they didn't. There was this new and trendy web browser called Firefox and some people use that and some people wanted something that appeared to standards and they used Opera. So Jason would be using this brand new JavaScript thing to allow people to do fancy interactions and he'd get it working in Internet Explorer and various members of ThoughtWorks would sort of come back and complain and go like, it's broken in Firefox and so he'd fix it in Firefox and then far more people would go, it's broken in Internet Explorer. So he'd fix it in both Firefox and Internet Explorer and then the one person using Opera would complain about how awful it was and he was going, he was looking for a way of solving this problem of constantly having a web app break whenever he couldn't and he made any changes and it was ThoughtWorks. He was doing this as like the member of the IT team that was working on it. There wasn't time or the ability to get people who worked in QA testing to help him so he needed to come up with something himself and he saw Ward Cunningham's work on fit functional integration testing. Now if you're not familiar with fit and to be fair I don't think many people are. It's basically a set of tables and then one column you have an action or something you want to check. In the next column or columns you have the values you want to do and then in the final column you have the result that you want to compare. And Jason saw this, completely misunderstood it and assumes that rather than doing high-level actions you wanted individual interactions with the web browser and thus the first version of Selenium before. Now this was an internal tool but he liked it. He was a big fan of open source and he went to Paul Hammond and Brett Pettichord and asked whether he could open source it and they went, yeah, I'll let that be. So they open sourced it and that was the original Selenium version that everyone had. Now the problem with the initial Selenium version that everyone had is that it was all based on... Okay. Do many of you write pages in old tables? For those of you watching that, I'm just about to go over their actions for coding apps that you don't even know. And there's a number of reasons for that. The first one is that 80% of the time it's running through an express of power. But to use the account, it's doing the same thing again and again. And so that isn't what happened. Selenium RC for a month and a quarter. And Selenium RC was designed to solve that problem. It was allowed to let users run code in the language that they wrote. Scripted languages, that's what they're doing. It was going to be a request. So Selenium RC came out. And shortly after Selenium RC came out, I was working in Australia. It was a sort of dual-exiled or a web browser. And around 30 years, that's fine because, you know, 19 years ago the web was simply based on a whole bunch of different apps that you didn't have to do. And myself and the colleague might have followed up to the talk. He was going, you know what, it's been required to every single rule of the orientation rule. And yeah, it worked, you know. But quickly, I thought, so hopefully the next few projects are ready. I started attempting to follow the advice they might be making. And started putting sort of focus on the skin around each of you, based on each of you. And that skin ended up with two classes that were sort of two different places. The first one was called Weatherlands. The second part was called Rats. It turns out... I returned from Australia to London. And while I was there, I was working on a project with Joe Bourne. Joe Bourne has been going through very, very similar processes where he had been attempting to put a couple of stories from the students around the professor. And he had two unique cases. The first one was with Eleanor, Robert, and Webber, which is another case in there, like all of our professors in that department. So when we rolled up that project, I had a colleague with Joe, so he might be an intern at the professor's. And I did it in the room, so thank you. And on the 3rd of January 2007, sitting on the 7th of June, I wrote the 2007 paper. And I was thinking, this will be done in a year from really after two years. It's now nine years in 2017. It's been ten years. It's also been a little bit over an hour. I was expecting it to be. This is a new toy project that we're going to use. And now there's a conference in the classroom that I'm applying for. And we've done some research pieces. We've refined the cases. If you go back to the book, it looks similar, but not exactly the same. And, you know, time to go on. We added the support part. The support part is for original designs to show people the kind of things you need to do to celebrate with Webber and to help with the emergency. And I don't think that's the size of the project. The evidence of the light. And we've used it specifically for Webber. That was written as an example of how this piece of paper has been developed over the years. It's written and stuff like that. So Christmas. In a slight change of pace. According to the songs, it's the most wonderful time of the year. You know, if you go back to the original meaning of Christmas, it was all around, you know, the birth of Jesus and things like that. If you look at the meaning right now, it's all about giving presents and massive consumption of all sorts of things, from money when you buy people gifts to far too much food where you sit with people on the sofa having even probably your own body waiting for you while someone offers you more food. It's a fantastic thing. It's an opportunity to get together with family, get to spend some time with people, you know. And the original meaning of Christmas is still there, I think, from time to time. But you may be asking, like, why talk about Christmas in the middle of the year in India? It seems like a not terribly obvious thing to do. And I went back through some of my old slides and had a look at presentations I'd done. And I believe it was in 2013 when I originally stood on the stage and went, you know what? We're going to have Selenium III done by Christmas. Now, I've watched the video. I don't think I say which year that Christmas is in. But sometime during this conference, it's actually going to be the Selenium Christmas. We're going to ship the Selenium III beta, which I think is going to be good fun. There's still a couple of changes that need to land, but we're on track and it's going to be held together with hope and good luck and probably sticky tape and a certain amount of profanity from Luke and myself as we try and outweigh the wrinkles. This is Trindy Vasapadoe. He's sort of doing diagrams and comments and making sure that it's all going to be recorded with posterity. Yep, excellent. Give him a round of applause. This is going to be hard work. So Selenium III, what's in it? How many of you are using their web browser interfaces and APIs? OK, you're going to love this because they're still there. If you've been following the advice of the projects that we've been giving for about five years now, Selenium III is just going to be a drop-in replacement for you. You'll just be able to upgrade the jars, upgrade the links from 2.53 to 3.08 beta 1 if you're feeling brave, and then file bugs and tell us that it's all working great. The web driver stuff, exactly the same. How many of you use Selenium RC? OK, it might be a little bumpier. We'll cover that in a bit. The reason for that is that how many of you use the HTML table thing? Good, almost nobody. Selenium IV, the major change, the reason why we're bumping the version number, is we're ripping out Selenium IV. If you're not familiar with what core is, I'll cover that later. But one of the important things is, although we pulled it out, your test will still continue to run. We're emulating as much of it as we need to, and we have a test runner for the HTML table. Do you think I put the wrong font size in there? Never mind. So your web driver tests, if you switch from Selenium II to Selenium III, your web driver tests will continue to work. The underlying classes haven't been modified. The interfaces haven't been modified. The implementations haven't been modified. It will continue to work exactly as it has been doing for the past. It's going to be good. If you use Selenium Grid, there are folks who use Selenium Grid here, right? OK, Selenium Grid, if you're not familiar with it, is a mechanism for allowing you to run tests in parallel on a fleet of things. That will also continue to work. That's quite an important thing. So if you've been following the advice of the project, if you've been following what we've been saying, if you've been using the web driver interfaces and APIs, you're going to be just fine. So Lenium RC, there are a handful of people who still use it. My advice, really, really, honestly, truly, now is the time to stop using it. I would have said nine years ago was the time to stop using it, but maybe five years ago, when we really still have Selenium 2, it would have been a great time to start making that move. The APIs, the Selenium RC part-side thing, they're still there. So your tests will continue to be fine, which is probably a few steps forward. But wow, I've been on project for the past time. So now, the code will continue to be fine. The only difference is that instead of the people who use the old Selenium, what we have is we have a web driver back in the back. So rather than being based on the original Selenium, we will instead have some back in the back. So everything is now sitting in the back. Now, this means that there's going to be some subtle differences between what you are running now with Selenium 2 and what you will be running with Selenium 2. So as part of your update strategy, just pull in the new job, run the test, and figure out what's going on. There's probably going to be a couple of suspensions. We've done our best to be both the both the factory. There's always something that goes wrong. So your existing investment in the RC class will continue to work, but you're going to need to do a little bit of anything in the back. It would be easier if you're running with a web driver. If you've never tried the migration with Selenium 2, a web driver API, it's daunting, but it's possible and it's good. Jason Labor at Selenium from London gave a really good picture of that. Google had literally done that side of that when they did it. Not hard. So I've been talking about Selenium 4 a certain amount in the presentation. You may be curious to know what it is. I know that some of you can think of the project there. So going back, Jason Huggin wrote a sort of version of Selenium 4, running inside the browser. And then Selenium RC, of course, did basically the same thing. Selenium 4 is that sort of meat, that massive ball of garbage that sits in there. It runs in the browser. And it runs in the browser because, hey, that's the end of the page. And because it's written in JavaScript, when the new browser comes out, chances are it will get so much better because JavaScript runs everywhere. I mean, it runs quickly everywhere, but it runs everywhere. How many of you have the opportunity to maintain a modern JavaScript application? Just a handful of people. How many of you have worked on a code base that's 10 years old, a few more people? Code bases that are 10 years old, despite the best intentions of everyone who's involved, tend to get a little bit crusty around the edges. It tends to be, like, somebody goes, I just need a quick hack. And then they put it to do something like this. Normally, like, 20, 30 tricks this, the web version. And Selenium 1, rich JavaScript application. Nowadays, people have even stopped talking about Ajax in the same way that people have stopped talking about UHDNL. The HTML, dynamic HTML, HTML, rich JavaScript. Trying that API around both of them. Luke is saying he used to do that. It's over now. So yes, the web has evolved. And the problem is, JavaScript is fantastic, provided you don't want to do anything sophisticated. Like, the interactions that people do with the modern web applications are incredibly complicated. When I was working on Google Wave years and years ago, there was a thing where you would be able to drag from the desktop into the application, but also from the app onto the desktop, and that would have two-way communication. And there was no way to test that into your JavaScript. Drag and drop, if you've ever read the sequence of events that get fired. It's previously confusing and very, very complicated. Works when you simulate an event inside JavaScript, if you go like, hey, I'm going to fire off all the events, I'm going to call click, I'm going to do all the things I'm meant to do. The browsers go, this event has been generated by the DOM, it's been generated by something that could be a malicious script in the page. So we're not going to trust it. And it sometimes goes down to different postparts, which means that emulating user inputs is incorrect. All that means is that a pure JavaScript implementation of the APIs is unwise and modernized. It's not scalable. It will continue to fail in new and interesting and novel ways, and those ways are going to be incredibly hard to fix if they are fixable at all. And because of that, we need to take out the slamming core implementation, because effectively, it's making the broken promise to our users. And our promise is it works, and it's broken because it doesn't in many of the cases it's in now. But people have tests. If you use the Selenium IDE and you export a table, you're effectively using Selenium core. Those HTML tables are the original grammar that Selenium used in order to do its work. And you probably want to keep those tests. Only a few years ago, somebody was talking about how they had a million port tests running, and that's how they scaled it, which is alarming, because we've just ripped out the thing that sits on top of it. Fortunately, it's code. It's Turing complete. You can do anything you want. And we have been working on a new runner so that you can just drop this Selenium-free beta into your screen, that will be referred to as the legacy package legacy. All right, I think there's only a handful of people who find that as funny as I do. But that's OK because I get to name them. So the legacy package contains the old Selenium classes. If you drop that on there, you'll get the new core runner. You'll be able to run it using the same flags that you used to be able to. And that will allow your existing Selenium core test to run. Now, this is the one that's going to cause the most problems. And the reason why it's going to cause the most problems is because the underlying technology is no longer present. We emulate it as best we can. But it's an emulation, it's not perfect. There are going to be bugs, there are going to be problems. Let us know what they are. We think we've got most of the use cases covered off. There is one, which is if you use JavaScript extensions, then you're going to end up with some undefined behavior. So if you're a super sophisticated user of Selenium IDE and you're using all the tools and resources, you're going to find this the hardest with a lot. At that point, it might be easier to export your tests, either as RCE or A-Log for in the modern world, web driver, and do some work around keeping that up. Makes sense? Sound OK? Good. Excellent. Lots of my slides don't have pictures, don't have words, they just have pictures. There's lots of words coming up. I apologize. But if you're going to take a screenshot of anything and just go like, hey, look, this is what I need to know, this is what you need to know. With the language findings, Python, Ruby, you'll just be able to download them, different install, easy install, bundler install, gen install, whatever it is that happens to be trendy today. Node.js install, npm install, cpan, what else is that? Naven. Naven, Nougat, you know it. Anyway, I'm going to talk about the Java stuff, because that's where most of the action is happening. Most of the client languages actually, it's even simpler than this. So in Java, there'll be Selenium Java for Selenium 3. That will contain just the web driver classes and the support libraries and stuff like that. So nothing that depends on RCE or core Apple. If you drop that in and you don't update any of your dependencies, certainly any code that uses code from con.sortworks.selenium or those original Selenium packages will no longer compile. And I'm OK with that, because you might be moving away. There is a separate standalone server, the Selenium 3 server. That's Lightweight. Lightweight has been reworked. It sits on top of updated versions of the libraries that we use. It's command line compatible. So if you have build scripts, which are incredibly complicated and no longer maintained by anyone who works for your company, anyone have those? All of you have people looking up your build scripts and know exactly how they work. Why am I impressed? I've never seen that. That's amazing. OK, so this doesn't matter to you. But it's pin compatible. You can drop it in. It will continue to work. And then there is the amusingly named legacy package. This is a new dependency that you can fill in. It will give you the old Selenium client-side packages, Selenium, default Selenium, the old weight classes that you used before you had the ones in the support package, bits and pieces like that. It has the new HTML table, the so-called Selenium core runner, sitting inside of it. If you add that, then the minus HPinalSuite flag for the Selenium preserver will suddenly become active. And you can run your tests exactly as you used to without needing to print anything. This also contains the WebDriverback Selenium. So we haven't got the old server-side. We haven't got Selenium core. And what we do now is when we want to run things, we just use the WebDriverback Selenium, which is like Java gets a bad rep for complicated names. But I think it's pretty clear that WebDriverback Selenium is an implementation of the Selenium interface backed by WebDriverback. Like I say, we've tried to be bug-compatible, but probably pretty close. And then the final thing that we have in there is a remote endpoint for the SE3 server. So if you start up the new Selenium 3 server and it detects you've got legacy on the fast path, it will automatically set up the old Selenium server endpoints so that your client tests don't need to be updated. They can continue using the old APIs, the old HTTP endpoint. And that will work exactly as expected. And the reason why we did that is to make it easy for people who work in a mixed environment, whether you've got Python, or Ruby, or CCR, where there isn't a complete WebDriverback Selenium to continue to have their existing test work. Like this is really important to us. Your tests are the thing you've made a huge investment in. They're the reason why you're using Selenium, rather than some other tool. We have absolutely no intention of making you throw that investment away. That's super important to us. And so we put a lot of effort into trying to make sure the back is compatible, even as we move the project forward. Do come along to the bug back that Julian is facing at the end of the conference to try out the beta and let us know where the problems are, where the rough edges are. It's also why we're doing a beta, because we want to go, we think this is pretty solid, but we want to be sure, and the feedback is important. So those are most of the key things you need to know. There's one other key thing you need to know, that is there is no Selenium core. It has gone away. I mean, we emulate it. We do our best. Your tests should continue to run then after what format, whichever API they use, but there is now no Selenium core. Audience participation. How engaged and energetic are you all? All right, before we do this, everyone stand up. Take a deep breath. OK, are you ready? Because what I'm going to ask you to do is just repeat after me. Selenium core is no more. OK, you can sit down. Thank you. Like, if there's one thing you take away from this talk, I think I've made it clear. I think I've made it clear, but I just want you to take this away that Selenium core doesn't exist anymore. Nada, yet, nothing. It's gone. If it hadn't been nailed to the perc, it would be pushing up the daisies, so on and so forth. It's gone to join the client. It doesn't exist anymore. It is defunct, gone, taken away, no longer present. OK, are there any questions about that? OK, just in case I have prepared a quick FAQ. FAQ, frequently asked questions. Does Selenium 3 and the new update impact Selenium grid? Answer? No, good. What about Selenium core? Is that still there? No, it's gone. I beg your pardon? Selenium core is gone. Good, you see, the brainwashing works. Is it really gone? Yes, it really is gone. It isn't there anymore. I actually deleted the code with relish. It was so much fun. And then I went through the Java code, and I did the same thing. And then I spent the next week fixing trends. It's gone. It really has. I mean, it's emulated with a test runner. The RC APIs are present in the leg RC package. And there's a web browser back implementation for that. If you're using the table stuff, there's a new runner for that. That functions. I think that's what I'm going to say about it. Your existing test will continue to work. The technology on which those tests were written has been migrated. But your test will continue to work. OK, good. So Selenium 3, the beta, come in during this conference. As soon as Luke and I manage to sit down and make the magic happen by swearing at our computers curiously. Because that's how software development happens, right? Coffee, pizza, and profanity get changed into code. And then things get shipped. And everyone goes, yep, that appears to be a bug. Years and years ago, I used to be a fan of a thing called defect-driven development. Defect-driven development is where you release some software. You go, it's done. It's perfect. And of course, it's not. Because the bug reports come in. And you said, I had a website. It's like, yep, what's the URL? It needs to be hosted somewhere. So you host it somewhere. And they go, I can't log in. You go, you need to log in as well. And so you do the login flow. And then people go, I can't add things to a shopping cart. A shopping cart? And so your entire development process is driven by bug reports. That's defect-driven development. In fact, in the early days of web browser, that's exactly what I did. Like, I took out the ability to execute arbitrary chunks of JavaScript. And then I waited until people came up with enough use cases where I had to cave in and go, like, yeah, I'll put it back. But it forced us to be really good emulation of user input and have a nice, clean API. So defect-driven development. Not recommended. It's a terrible idea. Don't do it. So Selenium 3-Beta is coming out. There are other things that happen in the world, outside of the beta. Just a bit of time to cover those. First things first, years ago, a long, long time ago, a continent far, far away, opera, actually, opera software were the guys that first suggested that we take the Selenium open-source project and we turn it into a standard with the W3C. The W3C, the worldwide web consortium, they're the people who post many of the specs and standards that we rely on day-to-day. Notably, HTML, up to HTML5, I don't know if you can see it. HTML5, CSS, I think XML is under there for years as well. Like every single good idea and bad idea, the specs tend to be hosted by the W3C if it's on the web. We have been working for an unconscionable amount of time on our web driver specification. If you go to w3c.org, slash dr, slash web driver, you'll see the latest version of the web driver specification. It is large. It largely covers the wire protocol that's used to communicate between the two ends, between your test running here and your service running here and making that all happen. But it also defines the behavior you expect when you execute a command. That W3C specification has been grinding on. We recently got permission to extend the charter of the working group for a little bit longer. We really, really, really, really, really, really, really want it to be finished because nobody likes to work on something that is endless. So we are working on level one. We hoped that we would get it done by the summer holidays. We obviously haven't. Arbitrarily, I'm going to pick Easter as the time it will be complete. But I'm not saying which year. So the web driver specification is happening. It's grinding forward. It's getting longer and longer. There is a face meeting in July. I think that will be where we come up with a final set of issues and push forward. Like bits and spec, that for a long time I've had PAB dragons, but I'm not quite sure what's going on, are being fleshed out. I beg your pardon? Actions, yes. Emulating user actions turns out to be incredibly difficult. As it turns out, it's figuring out whether something is visible. Like, you know, get text on elements. It should be easy, right? You just, well, whatever happens to be displayed. Browsers don't know what text they're showing to users. I have no idea how this stuff works. And apparently, the browser vendors don't either. Like, by the time you've gone through HTML, CSS, styling, and random things on the display driver, like what you see painted on the screen, almost nobody knows what that is. It's complicated. Now, the nice thing with the W3 specification is that you end up with vendor implementations. So is the opera driver, the Chrome driver, marionette. Opera did the very first version. And I remember them demoing it, and people being blown away by how fast it was. A little bit later, Google released a driver for Chrome, which was slightly embarrassing. Jason Huggins and myself were working for Google. Google had their own browser. You would imagine that somehow, the US mega-corp would be able to figure everything out and get the first influence out. But no opera beat us to the punch quite a long way. So the Chrome driver came out. There is a lovely video of somebody watching it run for the first time going, holy shit. We're OK with a bit of the bandwidth. Sorry. Holy heck, as it first runs. David Burns, who's been on the Selenium project for ever, has been sort of leading the team that is working on marionette. Andres Colson, who's got a lot of work on that, both in New Zealand, have been really important in respect for it, and also doing an implementation. So marionette is there. Each of the major browsers have their own version. There's an edge driver as well, which I thought I had a screenshot of, but it's done away with. Well, so the edge driver is kind of nice. Like Microsoft, who got behind the project as well. That's amazing. Like, who would have thought that Microsoft would be involved in something that is originally an open source project? And one of the reasons why we started with the W3C was to try and encourage people who were wary of interacting with open source to interact with us on a standards level. Because some companies have a full relationship with open source. One of those companies is Apple. Apple, I mean, look at this. I've got an iPhone. I use a MacBook as my laptop of choice. I never wear a watch, but I probably didn't get an Apple gift. They make fantastic bits of Kits, and they make great software, right? If you look around many developer conferences, you'll find so many people using Apple Kits. And it was always one of the things we wanted was there to be web driver support from Apple so that we could stop attempting to support Safari. Because Safari also turns out to be one of the hardest browsers in the world to automate. They announced at the Worldwide Developer Conference, WWDC, the new version of OS X, Sierra. And in Sierra, if you go to user bin, Safari driver, you have an implementation of web driver shipping with the OS. What this means, and this is really big news, like everyone on the team is like, yes! And everyone else is going up, like my parents are going up, what? What this means is that each of the major browser vendors are now supporting web driver as a standard. We have gone from a tech project with a handful of people working on it to an international standard that has the backing of all the major browser vendors. Like, that's a huge achievement. And it's thanks to the development team, but also the users, right? The reason why we're able to go through the standardization process is because people like you are using the product day in, day out, giving us feedback, telling us the things that we need to do to improve. We've been listening, we've been improving. And because of the widespread adoption, that's why the browser vendors are doing it. So, if it hadn't been for you guys, there wouldn't be a Safari driver, there wouldn't be an Edge driver, there wouldn't be any of this. You guys have purchased projects from a Toyana hobby to actually within WDC. So, thank you, thank you very much for that. You can clap if you want, or you don't have to listen to, have a nice cup of tea. Luke has done one clap. It's like the Zen Cohen. What's the sound of one Luke clapping if he's doing this? Which is a sign language for milk. Do you need a drink? Yeah, okay. Sorry, so, Selenium 4. Oh, crikey. So, yes, I mean, we are doing Selenium 3. That's obvious. The reason why we're doing Selenium 3 is we've ripped out a major API. It's always polite to bump a major version number when you do that. Just to let people know that there's a big change. Selenium 4, there is another big change coming. That is the one where we have compliance with the WDC wire breaker problem. So, this will be the version of WebDriver that it is to the WDC spec. It will be coming out shortly after the spec is complete. The spec will be complete by an Easter. So, yeah, I mean, we'll probably get Selenium 4 out by, what, Ada Valley or something like that. That would be appropriate, right? Okay, good. So, that will shift. Selenium 4 is basically, yeah, the W3C version of WebDriver. It should be good. But, again, it also should be a drop-in replacement. If you're using the WebDriver APIs, which the new legacy packages are and core runner is, then this will be a drop-in replacement. Unless you're running Grid, Grid will be the one place where you might need to do something about bits and pieces. But, the idea is that we'll be able, as we cross over from three to four, the last version of three and the first version of four will speak both dialects of the open source wire protocol and the W3C protocol. So, you'll be able to do a managed migration. Like, you won't have to break the entire world in order to migrate. Again, because we value your tests, your tests are really important to us. Having that stability is really important to us. So, yes, Selenium 4, it's a little way off, but that's what it's going to contain. It's going to be a change in the wire protocol. There is WebDriver level two with the W3C. Now, the reason why we are able to move forward with the specification of WebDriver with the W3C is because we keep on saying, we're not going to do that right now. We'll look at this in the future. And so, level two contains a bunch of stuff that we have hunted on and decided was too complicated. Now, we may have decided it was too complicated because the spec on which it depends hasn't actually been finalized. So, Shadow DOM falls into that category. Or it might be that actually it's still emerging in the WebDriver and Selenium communities and we're not quite sure what it looks like. So, mobile is a really good example of that. We know that there needs to be some form of mobile testing, mobile-specific APIs, but we haven't yet nailed down which ones are appropriate and whether there needs to be ones separately that is platform or whether there's some sort of coherent set that we can quiet over everything. With web browsers, we've had 10 years, 15 years of experience. We haven't had that long with mobile devices yet. So, we're not quite sure what that looks like. So, that's going to be level two. Again, that'll happen when it happens. But it's going to be really important to allow us to shift level one. The first version of this fact to have level two be on the way. And the final thing is, we don't often talk about this, but this is really important for the Selenium project. We are part of a group called the Software Freedom Conservancy. Have any of you heard of the SFC? Almost none of you. You might have heard of some of the projects that we do. If you, C++ code there, there's Boost. If you run continuous build farms, you might have heard of BuildBot. Does anyone use source control? A surprisingly few people use source control in this room. I advise you to do it. So, SFC, both Git and Material, are project members of the SFC. SAMBA, if you interoperate from Unix to Windows, that's the SFC, and obviously the Selenium project. What they do is they provide the support for doing all the legalese, doing with any money that we have. So, setting up the conference, for example, takes money, we probably haven't got the skills to do that, the SFC do. They provide the backup, the admin support, in order for us to run a successful open source project. And they are absolutely invaluable. And so, without them, we wouldn't be where we are right now. They also help look after our intellectual property, if there were ever any patent issues, please repeat the guys that are going to call for us and make sure that everything's clear. They are awesome, and we never give them enough praise and a shout out. So, I just thought I'd give out a shout out to the software freedom conservancy, and I hope that at least one of them makes it to the end of this video to see that. And with that, remarkably, I'm on time. Nuresh, you'll be pleased to hear. Thank you all very much for your time and attention. I hope you have a fantastic Selenium conference. If you have any questions, if you want to chat, I will be around as will other members of the development team. Thank you all. Have a great conference. Yeah, Nuresh is asking if we can take questions. Of course I can. Are there any questions? Okay, five. I'm sorry, yes. Is there one? No, we're in here. Oh, there it is. So, few questions. Okay. No, I thought that his chemical unit was provided as a separate project. It's a project. Any intention behind making it as a separate project? So, HTML unit being broken out into its own project. One of the things that we really want the Selenium project to be responsible for is the Selenium interfaces and classes and the support libraries, documentation and things like that. The people who are best placed to do an implementation of those interfaces and classes are the browser vendors. So, Microsoft have done implementations for Edge. Mozilla have done one for Firefox. Apple are doing one for Safari, which is great news. Opera have done one for Opera. HTML unit, that project. We want the HTML unit developers to be responsible for the HTML unit driver because they know they're too best. And sometimes in order to do good emulation you need to change the underlying project. And they are the people who are in the best position to do that. So that's why we spun it out as a separate project. Actually, that makes me to ask another question, right? But you inbuilt the Firefox drivers into the Selenium. Yes. So, I think we find difficulty at times when Firefox upgrades. So we have to be waiting for the Selenium release, right? Yep. So is there an intention to detach the Firefox driver? Yes. So, there are a couple of things happening in Firefox that mean that it's more and more challenging for us as the Selenium project is affected. The first of those is signed add-ons. So the latest Firefox release, you can't turn this off. There is a feature where your add-on needs to be done to go like it's okay for this to end. The developer builds a web driver on sign. So we have a problem there. The second thing, they're working on a project called Electrolysis. And Electrolysis is a sort of multiprocess model for Firefox. Chrome has had this for a long time, Safari has this. That's where if something brings down one site, it doesn't bring down every single tab, it just brings down that one tab. So it's process isolation done within the browser. And it turns out that some of the assumptions that the Firefox driver makes violate those. But good news, you don't need to wait for an update from the Selenium project. You don't need to use the Firefox driver. Marionette is the implementation of the web driver APIs that's shipped by Mozilla itself. It's release cadence is based on Firefox's rather than Selenium projects. So all you need to do is switch to their implementation. They have wired it in so that if you use a Firefox driver and wires it's in the program. If that's found on the path, that will be used on preference. So it's really easy just to do that switch onto the official Marionette product. Ultimately, what this means is that we're going to delete even more code from the Selenium project because the Firefox driver is effectively no more once Marionette is capable of doing it. And it's basically out of that. Does that answer the question? Good. I think that's great. We do have in the evening a Q&A panel with all the Selenium committers. So I would actually reserve questions which are more directed on those lines. If there's something more specific for Simon, maybe this is a good time. The project specific ones we can take it in the evening. I have a question for you guys. Can you use Selenium Core in a new, actually script browser might work. Because I mean, never read the JavaScript that's generated, but basically you detect that you're using some of these really common patterns. And then we have compiled versions of lots of those and we inject them into the script so we can take like razzabot.gettitle to grow absolutely nightmarriage amount of code. Yeah, pretty much. Yeah, you should have it. All right, are we done? Brilliant, thank you very much. Have a great conference. Thank you.