 Our next presenter is one of the best-runner of the New Zealand Heads. He won milestones like four or five already in Honolulu, and I have to read this, Liverpool Brightham Jersey, and as I mentioned before, Honolulu. His plan for this year is to run in London and in Berlin. And if we had to know people that were like furniture sellers or casino dealers, Dave had a job previously in bouncing castles. One cool thing about him and his children is that they have 120 Lego minifigures. I don't want to see a picture of that. What can Dave...? Okay, so I'm going to be doing a presentation with Henrik Skrubin. Unfortunately, he's not here because he has sickness in his family, so he's home looking after them. But I do have a substitute. And so this talk is the puppet show, and we have this and that. So until today, this guy didn't have a name, and I'm in the name of Henrik. So is Henrik. And I also want to thank Henrik for putting together most of these slides. He's done the job of the work with this, so... I did joke about I would put on a German accent as well for one of his parts, but... You don't know that. Okay, so I'm going to talk about animating Firefox using Selenium. And we've got the tools that go along with that, which is the Gecko driver and web driver. So, topics are becoming. Drive animation with Selenium. I'm going to talk about what is the Firefox driver. What is the success of the Firefox driver? And then I'm going to have to introduce some fox puppet. So, drive animation with Selenium. So Selenium is a Swedish tool for browser remuneration. It's most commonly used to write tests for web applications. There's not its own use. Selenium is an API for controlling browsers. So Selenium is a user interacting with a browser, which actually opens up lots of possibilities, fun things like playing games with the browser, playing with the instruments online. But yeah, most commonly it's for testing. It supports all the major web browsers. So Firefox, Chrome, Safari, it's not explored in Edge. There are multiple clients. Each of them provide a web driver API. So the official clients are Python, Java, Ruby, JavaScript, and .NET. There are also a few unofficial client bindings, such as a number of PHP bindings per, as well, and others. So an overview of how it works. You have your clients over here. So you have your Java, Python, JavaScript client. It means talk to a driver. In majority of browsers, this driver is a binary. There's running in the system. As for some reason, it's both a military browser for the commands to run the browser and carries out those interactions, those commands. For Firefox, it's been a little different. It's actually running in earlier drivers, and it was built as a Firefox extension. So that's what we have to separate actually. So Firefox driver is a specific driver for controlling Firefox. And it was built as a Firefox add-on. But when Firefox is launched, that's when the add-on is installed in the notebook. This add-on is unlisted. It's not uninstalled at all. And it's also unsigned. And the only reason for that is that it says security concern. Effectively, we have this add-on installed where the browser could be controlled by something in your notebook. It's been maintained by the Selenic community, and we don't have it officially supported it or contributed to it. So an example of some code that would control Firefox in this case may not be particularly readable to see. So we import this in Python. So we import the Firefox package. It's going to show an object we're calling Selenic. And then we're calling the get method here. And we're getting the add-ons done as a little bit more website. Selenic, essentially, is located in the attractive elements. So we're finding an element that's on a build, search, and we're simply dot dot dot plus. So we're searching, essentially, we're looking here for the search button we can accept. So we're searching for the dot dot dot extension. Well, the back button here is fairly out there, but it's a screenshot of what was at the running that code. So, unfortunately, or fortunately, it turned out, the Firefox driver has been deprecated since Firefox 48. And that's because Firefox 48 and another one of the add-ons has been stored unless they are signed. So the Selenic project decided not to sign the add-on, which a regular could have done. Fortunately, we have another solution and a much better one. And that's Marina and get their driver. Selenic was first introduced in 2012. It was introduced for the Firefox OS project, which was our opponent system for mobile devices. It is an automation framework for get-go-based applications. Last time I was in first-down, Henry and I gave a talk about promoting Firefox OS. We're really using that in that too. It's now built into Firefox and Femmick. Femmick being our Android version of Firefox. And it can control both the Chrome and content space. So typically, Selenic is for interacting with the content space that is your web applications, websites. Marina has the ability to escape that and go into the Chrome. And that's basically everything else that's in the browser interface. So your tab bar, your URL bar, buttons, etc. And the method of communication for this is the TCP soclips. Get-go-driver is a proxy for what is the web-driver specification. So the web-driver specification is something that started, and the discussion that it started in 1.2.2.9 is being carried by David Bones and Simon Stewart. David Bones, with me, has been out in Simon in the town of Fink. And the other specification is that any browser in the spec can be coordinated. So the spec is now close. I believe within a week it's going to hit a candidate recommendation. And the goal is that this will be a recommendation by the end of this quarter. The huge win we had with this, and we thought that it was the only way in which we would get this, is by making that a specification, Similion now has been adopted, the web-driver spec has been adopted by all those browser members, which means that the Similion project itself doesn't need to worry about how to interact with and automate any of the browsers. Similion only really needs to implement the web-driver spec, and the browser vendors are providing a compliant driver of browser for that. So it means that we now have support from Apple, from Microsoft, and so it's actually the browser vendors doing this. So Gekko Driver is an API that complies with the spec, and it translates the calls that it receives from this with Marina. So Marina is able to automate Firefox, or any Gekko-based application, and Gekko Driver receives the spec compliant, and it translates them so that they can be carried out of Marina. And it's not yet feature-complete, so this is partly because the spec is in the low stages of camera recommendation. There have been some interview-like learning changes, so this should be soon, hopefully soon it should be feature-complete, and I believe Gekko Driver may be the first complete implementation of the spec. So this is what the diagram changes to much more consistent. We now have Firefox in amongst the browser, and we just have the driver. So in our case, this is Gekko Driver for browser, it's Chrome Driver for Chrome, it's Safari Driver for Safari, et cetera. And most drivers being provided by the browser vendors also means that they're responsible for fixing and making sure that they're not in any questions. And the other cool thing is there's no test changes necessary. So there's an union coin on this side. It starts using the driver specification, and the driver's understanding that. So that was changing quite a bit. So... Okay. So it's using Fox Pepper. So Fox Pepper allows you to interact with Firefox using some of them. It's kind of a bit weird to say, but here it's actually Firefox itself. And like I said, no, you can do nothing just with some of your methods. It allows you to switch into the Chrome context and interact with the buttons, the URL bar, et cetera. And so by extending the web data spec in Gekko Driver, it allows us to do more. So what Fox Pepper does, it's a platform package with a simple API that allows you to locate and interact with the Firefox UI. It supports the latest Firefox release and pre-releases. And from the next version of Extended Sport release 52, values should be supported. So the idea is that if you're using Fox Pepper, you should be able to use any of the latest versions of Firefox. And ultimately, it's going to be used to test Firefox itself. And normally it's going to be used if you're testing things like installing add-ons, extensions, and both may be using it for Firefox UI. So here's some code which is actually linked to the app that is in the middle of it, because it's going to struggle how you would installing add-ons without using Fox Pepper. So the thing to note out here is, similar to the field, we're getting a web page referring to an element that happens with the store button for extension. And here the switch in the context. So it's with seemingly the context of Chrome. So everything in this indentation is now going to happen in the Chrome space. And then essentially, we're getting a notification. So when you click and store it up, and you're going to need to have a notification directly down, it needs to click and store, and you get a confirmation. So here we are, clicking the store button at first notification, and then defining the next notification and clicking the close button and that. This time, we didn't actually get that. We'd actually be more of a base. Most likely, we would have to have explicit writes here, because as soon as you click the store button at the add-on, no instantly get missed notification. You first want to wait for that to appear, then you can interact with it. Then you've got to wait for the next notification to appear when you can interact with that. This is the code with FoxPuppet. So there's no show of FoxPuppet instance here. It has a browser property in there, which basically is our initial browser window. That's all we're using in this demo code. Again, we're using Selenium to open up a web page. This is what happened in the context space. We're finding our button to click and store. And then these two ones here is all that we're doing with FoxPuppet. We're seeing that as a wait for the notification. It's best to have a notification that you're expecting, and then we're clicking the store button and the store method here. And then after it's done, we're waiting for the add-on to store complete notification and we're clicking close on that. So here's a short video to show you that happening. I've slowed it down, but maybe not enough. So we're clicking this button here. We're waiting for this. We're clicking the store. We're waiting for this. And then we're clicking close. So we're doing that last step. It's okay. Of course, I want to talk about FoxPuppet. At the moment, FoxPuppet supports simple window management and interacting with notifications. I saw a poll across this morning that adds some support for the tab bar and tabs. There's a lot more to add. One of the advantages of building our automation for FoxPuppet itself on Selenium means that we take advantage of the wealth of Selenium experience that contributors may have and hopefully attract people to help us in building our tools, our tests, and our phone. Any questions? I'm not sure how I'm doing for time. Does it work headlessly as well? Or is it always sharing a window? The question is, does it work headlessly? No, because you can't run Firefox headlessly. You can run Selenium in Docker, which effectively makes it headless. It can run as an XFB on Linux and effectively makes it headless. But no, there's no true headless for Firefox at this time. The question is, do I have an example using WebGL? I don't have enough experience with WebGL. When we're talking about Selenium and Web documents, we're locating elements in the DOM and interacting with them. If something doesn't appear as an element in the DOM, it can be quite difficult to do, but not impossible. I've had some experience using Canvas. It has that kind of issue. It's just one element, and you can't see everybody does within that. The way I've worked around that over the past is for the application to provide some data that is only really exposed, the intention is only exposed to the test, and we can execute JavaScript. We can give information about the current state of the application. And based on that, we can interact. We can send keyboard keys. We can also use the mouse to click. There's also an Advanced Interactions API that is not yet complete in Gecko Driver, but will allow much richer mouse interactions as well. But you need to get some information out of either the DOM or JavaScript, something like that, to be able to interact. Can you use FoxPobby to interact with the browser and the microphone? So the little notifications that pop up ask me whether I want to share permissions for... Yeah. Yeah. So the question was, can you use FoxPobby to interact with the permissions, notifications in Firefox? I would only say no, because at the moment we haven't written regions or objects that represent those, but there is no reason why that wouldn't be possible. And most likely, we would do that as soon as we want to migrate some of our existing tests, the tests that that works. So yeah, it should be fine. Yes? What about asynchronous JavaScript execution? Do you have any examples of what that looks like when we're through FoxPobby? So Samillion has two methods for executing... Can you give me the question? Yes. The question was about executing asynchronous JavaScript. So Samillion has two methods. The web drive spec has two methods. One is execute JavaScript or execute script. The other one is execute asynchronous script. So they're both possible with Samillion, and because they're possible with Samillion, they're therefore possible with anything that builds on top of that. So the question was, how would it deal with cross-site scripting? So I believe the cross-site scripting used to be a problem when Samillion was essentially all built on JavaScript, but now that it's built effectively into the browsers, it's no longer a problem. I'm not sure about executing script. So typically, I find I really need to do the execute script using Samillion, because Samillion is tools for simulating a user. So if a user can't do it using something that's on screen, there are other ways of doing it, such as executing script. But typically, you're then not quite user-slim for its intended purposes. So typically, I would say, if a user can't do it, they might better do it with Samillion. There might be issues with that also. Thank you. So slides are available in mind, and there's some contact details for me and Henrik. So if anybody has any questions, please get in touch. If anybody is interested in helping us to build out FoxPuppet or to work on migrating our tests to using it, then that would be appreciated. Thank you.