 Thank you for having me here. And I just want to say before I start how great it is to see so many people here interested in building for the web and on mobile, web on mobile. It's really encouraging. And I really appreciate Google organizing this event and inviting us here. It's really great to see. So my name's Ben Kelly. I work at Mozilla. And I'm going to talk to you today about what we're doing to support progressive web apps and the mobile web in Firefox. See if the clicker works, it does. I'm on the DOM team, the Document Object Model team, which doesn't sound very exciting, but it actually is. There's always something new, a new surprise. It's really a bunch of C++ and maybe Rust developers trying to write APIs and tools to help web developers to help you guys provide a good experience for people on the web. Being C++ developers, we often get things wrong. But in this case, with progressive web apps and these set of technologies and APIs, we really get the sense that there's a lot going right here. And we're very excited about it and working hard on it. So I guess this is a way of background a little bit. I joined the service worker effort and the DOM team a little over two years ago. I'd never implemented a web API before. And my new boss, Andrew, was like, you know, why don't you join service workers? It's been going for a little while, but we want to ramp it up. So a lot of work there, but it's not too hard. So we should be done in September, maybe? And that didn't happen. And it's right, well, maybe six more months. Yeah, that's a long time, a long, long time. That didn't happen either. And eventually, we just said, please stop asking us. And we don't know when we're going to be done. There's a very complicated API. And I give credit to the people I work for that they gave us cover to do this, because there was a lot of pressure coming from all sides. So finally, we were able to enable it to ride the trains, as we say, to go to our release channel December of last year, and it shipped in Firefox 44 in January of this year. So a year and nine months thereabouts. So it's been a long road. I think it was worth the wait to get to do it right. Some of the things we spent time on was security, as I'm sure you're aware. The web is built around the same origin policy. We use URLs to tell if a resource is safe for a site, if they're coming from the same domain, the same origin, one way to look at service workers is a great tool for lying about URLs. You ask for a URL from site X, and you give it a URL, the content from site Y. And if your security is based around URL checking, you need to build a secondary system for this to maintain the same origin policy. That being said, we have since changed the spec so that the URLs actually get flowed back from the service worker to the outer bits of the browser. And so no one has implemented this quite yet, Chrome or Firefox. But I think it should help make the security story a little bit easier for browsers coming along later, implementing it next, that they don't have to completely build a separate tainting system in their browsers. So hopefully that will speed things up for the next set of browsers. Also we found that there was some room for improvement in the specifications. Junkie, Jake, and Alex have done a great job. But it's one of these things, just the way stuff happens where you write an explainer, you get an initial implementation, you translate it into some spec text, which is almost precise, but not quite. You can't execute it. And they're invariably bugs in the spec text. And when we came to implement it from the spec, we found, for example, had to brace conditions and various unexpected behavior that I would pester Jake and Junkie about. And that's all been fixed now in the spec. And again, we hope that this took a while, but we hope it will speed implementation in later browsers and helps maintain compatibility between Chrome and Firefox today. We also took a lot of time working on tests. The Blink team, let me back up, a lot of browsers, historically, we obviously have a lot of automated tests that run. Most browsers typically have had their own test suite. In Gecko, it's Mokey tests. I don't quite know what the other browsers have. But the Blink team did a great job writing for this new test framework called Web Platform Test. It's a standard place in the W3C that lets us share tests between browsers. It wasn't quite easy to import because they still were using some of their own infrastructure, but we imported that, upgraded it to the standard Web Platform Test, and wrote a lot of new tests. And it's now been uplifted back to the main repo. And I can just hop out of here for it. So you can go and see. There's just a ton of tests. And this isn't even Attica. We need to keep adding more. But getting these tests is the best way to make sure that these features work across browsers. And it's great now that we have a place where we can share tests like that. We also did a lot of documentation whenever we implement a new API. We have a team of people who go and document it on Mozilla Developer Network. So if you have questions about the API, you can find it there. We really want this to be a resource for the web, not just Firefox. So if you see anything that needs to be fixed, it's a wiki. You can fix it, or let us know, and we will get it fixed. We also had a group of engineers, Salva de la Puente and some other engineers. Salva's here today, if you want to talk with him. Some other engineers built a great resource called the Service Worker Cookbook. It's just at this site. I'll blow this up so people can see. I'm not quite sure how you say that, so we call the Service Worker Cookbook. But it has a large number of examples. Again, not using any frameworks. If you want to learn just how the service workers work directly, you can work through some of these examples. And it's varying levels of detail. The B means beginner. I means intermediate. And the A means advanced. So you can see there's a number of different use cases here. So we're trying to help with the developer outreach as well. So all that took time. Let's shift. And the great news is we're seeing people use it. This data is pulled from our beta developer edition and nightly users. By default, we don't collect the telemetry data on our release population. Unless they navigate through the advanced menu and click, please collect more information on me. Not many people do that. So this is largely beta developer edition and nightly. So the absolute numbers are not as significant as the trend here. And there's a clear up-and-to-the-right trend. And it's accelerating, which is great. When I work nights and weekends, I tell my wife that what I'm working on is important. And it's great when people actually use what we're working on, because it means I told her the truth. We've also been working on push, which shipped in Firefox 44. This is the web push, push notifications. We also have HB2 push, but I'm not talking about it here. But it only shipped on desktop for now. We are working on Android support, but there's a lot more operating system level integration that needs to happen here. We're really hoping it would make 48. But just before this meeting last week, I got some news that we found some additional bugs. It'll probably ship in 49. It's more likely. And you may be saying, push on desktop, is that even useful? Most people think of it as a mobile feature. Well, I use it every day. I probably spend too much time on Twitter. But when I'm supposed to be working, I have Twitter closed, and I can get push notifications for messages and mentions. It's a feature that they have relatively buried in their settings currently. I think it's a little bit of a soft launch. But it works every day. And I don't think I'm the only person using it, because, again, the trend here, the absolute numbers are not as important. But the trend is definitely up into the right and increasing. So that is also good. We're seeing adoption, which is, I think, a sign of a good API, or a useful API. Some of the work we've been doing on push, Martin Thompson and engineers from the other browsers have spent a lot of time standardizing the back end. When I believe Chrome just shipped support for the standard web push API previous to that, I believe they're using GCM, Google Cloud Messaging. But now that we have a standard, it's something that makes it easier for the back end and the way sites can integrate with those servers. Because it does require this extra server integration on the back. We also built a reference implementation of the server, which, if you're interested in this sort of thing, the back end servers describes all of our architecture. If you want to know how a push message actually flows completely from when you post it all the way back to the browsers, to your users, you can read through this documentation. These slides will be available after, so you can see the links. You probably wouldn't run this server yourself, unless you're building your own browser, but that's possible, too. Again, we have documentation at MDN and the service worker cookbook I showed earlier has a lot of examples for push as well. Let's see. So next, I want to talk about DevTools. We, I'm going to break out here and do a little bit of a live demo. And in the beginning, we shipped something that was fairly bare bones, because we wanted to get service workers out. Very similar to, I think, it was Chrome internal service worker. I can't remember the exact name of the equivalent in Chrome, but fairly bare bones HTML page for managing these things. We now have support for worker debugging. So originally, we did not have this, but currently, it's really only usable for debugging fetch and push events. We're still working on support for debugging the install process, which is obviously a big use case. But let me show. So instead of about service workers, you can now go to your DevTools menu, click on service workers, and it'll bring up this new about debugging page, which will show all your service workers. I'll just open a new window here for my slides, which have a service worker. That's true. You can see now that I have the service worker for my local host is now running because it has this push and debug buttons. If I push debug, it will open a full screen debugger because I'm in full screen mode. And you can see the service worker that I'm running. And let me, sorry, this is probably small for you guys. And I will blow this up. I'll set a break point in the fetch event handler. Pull out a full screen for a second. And I can now reload this and it will break. Sorry. And you can do the things you would expect to do. You can inspect the request. You can see that, well, I did a reload. So it's requesting all the resources with no cache to revalidate everything. You can see that it's a navigation. You can see what the refer policy is. All the stuff you expect to do. So I will close that. Go back to my slides here. And these are screenshots of what I just showed. Network panel, I will, actually, I think I'm just gonna use the screenshot here. But network panel, you can go and, excuse me, network panel now shows if a resource comes from service workers. You can see here that in the transfer type, if it came from a service worker, it will show you. Again, we shipped something bare bones. You would get lines in network panel, but it wouldn't really show you where it came from or what happened. You just see nothing for the timing. We are still working on adding timing traces so you can see how much time it took to start the service worker. But again, we're making progress and we can iterate now. We also have a storage inspector, which this one I will show. Again, you may go to DevTools and be like, where is my storage panel? Well, you have to go into the tools here to enable it. This checkbox here. It's not on by default currently, but if you come to cache storage, you can now see all the resources. You have, again, a nice feature. You can access this stuff through console using the API, but this is just a little bit nicer. Let me move on to the next big feature. Features that we're working on. Sort of what we had been doing. Here's the clicker again. Manifest and install to home screen. This is something people care about a lot. Particularly the prompt. I think Nolan Lawson said at one point that I think it was him. He really liked people like this because it's almost like the browser advertising for your site. So it's an important feature. We've been working on it a lot. Marcos Casaris, sorry if I'm mispronouncing his last name, has been working on the Manifest spec. He's one of the editors and he's been working on the platform support and that is largely implemented and ready to go. However, we're not shipping yet because we still need to integrate it with our product. Firefox for Android and Firefox desktop. The product side is a separate team. So we're working to make that product integration happen now. It's taking a little bit longer than we'd like but it is coming. You may have seen some screenshots on Twitter and I believe this was shown at Google IO. This was an experiment we ran in Firefox for Android to show what a prompt might look like just to see how people would react. I just want to... So this is something we could do and I just want to highlight because I think there was some miscommunication around this. This is just an experiment. It's not shipping yet. We're still working on it and we really need to get some designers to sit down and figure out how we want to do this. Do we want to do a problem like this or do we really want to do something more like Alex suggested in blog posts like ambient badging? We need to figure out what the right answer is for the users. The other interesting thing about this is this demo or experiment did not use manifest at all. It's installing the home screen as a bookmark using the link and meta tags in the document. So this is actually a nice example of progressive behavior here where the feature isn't there and yet it's still providing a good experience for users. So just to make clear, we don't have a release date yet for add to home screen. I just wanted to clear up any confusion there, but we are working on it. Background sync is another feature. It's well into development. Actually, just as I was sitting over there, Fernando Jimenez Moreno, again, I'm probably pronouncing his name wrong. I apologize, landed, not landed, but he submitted all his patches for review and he has patches that are working and so excellent. I was actually expecting that to happen later because he's getting married. I have visions of him sitting at the church, like uploading patches before the ceremony. But so I'm very optimistic that this feature will land in the Firefox 51 timeframe, assuming code review goes well, which it will. And this is a demo he made. I was going to try to live demo this, but I thought that using non-standard patches and a custom build in a presentation was tempting the presentation gods too much. So here it's showing that when it's online and you register for background sync, you get the note, you can get it immediately. If you're offline and you get a register for background sync, you don't get the event immediately until it comes online and then it fires. So it's a pretty simple demo. It's not terribly flashy, but it works. And again, this is something we'll probably ship mainly on desktop first. Support in Android will be there, but it's not going to be tightly integrated at first with the operate, with like, I believe Android has a background sync task or process that native apps can integrate with. We will eventually integrate with that for features like this, but the initial feature launch probably will not. Let's see. And then finally, there are a lot more APIs that we're working on that are related. I forgot I had the clicker here. And I'll just go through these quickly. We're doing a lot of work. We've shipped the full cache API, including things like ignore search. So if you're doing a cache busting parameter, search parameter, you can use ignore search in your cache.match to easily ignore that cache busting parameter. We've shipped request.refer and support for the refer policy in Firefox 47, which is our current release. In our next release in about four weeks, request.cache will reach release channel and this will let you, you won't even have to do a cache busting parameter, you can just do fetch, URL, cache, no cache, to avoid even the need for cache busting parameters. We're working on SRI integrity support for fetch, so you can set integrity value on fetches and then in your service worker, you'll be able to inspect that integrity value. Those patches are mostly reviewed, should land soon. Streams support, Streams API has begun. It's probably gonna land in stages with pure JavaScript streams, the ability to say new readable stream first, so we can get it in the tree in SpiderMonkey and run the tests on it and then we'll land our binding support afterwards. So we're probably hoping to get the JS Streams into 50 and then 51 and 52 will have binding support and fetch body stream. And I'm really looking forward to this, getting Streams spec into more API so that we can use this in more places than just fetch. And we've also begun work on storage API which is the API which lets sites request persistent storage offline, so if it's your hotel reservation or your airline boarding pass, the site can say, don't delete this without asking the user, because the user's gonna be upset if it's gone because they're gonna need it. So this has just started, it has a lot of user experience elements to it to know how to manage storage so we don't have a release date yet for this. I think I just wanna leave you with the, Mozilla cares about the web and we care about the mobile web and we're spending a lot of time and effort investing in that and trying to provide you with the tools that you need to provide good experiences for your customers. So we're really looking forward to see what you guys build and if you have feedback or concerns or feature requests reach out to us. I'm here today, Salva's here. We also have Brian Clark who's a product manager for our DevTools team is here also. Come and find us, let us know what you think, where you'd like to see the platform go and I'm really looking forward to seeing what you guys build with this stuff. It's gonna be great. And these slides are online. It's about five megabyte download so I wouldn't do this on your mobile necessarily but it does offline with a service worker once you download them first. So if you wanna follow any of the links or check it out, they're available there. And it's on GitHub too. So thank you very much. I appreciate time today. Thank you.