 Hi everyone and welcome to our presentation about predictability, but first things first we are Rick and Rob Which kind of sounds like two cops on stakeout, but you know just just go with it and Since I got the opportunity to put together this slide. I got to pick which picture to use of Rick This was the best picture that confide of Rick. Thanks a lot This is Rick. Hi, I'm Rick. I lead a team of software engineers working on the web platform and My name is Robert and I work with develop relations around feedback and community and then much more This is the worst picture of me available on the internet don't check and The things that we're going to talk about today is what is predictability You've heard many interesting talks today about new features and all the progressions that are happening on the web But what we believe we're covering today in this talk is the most important thing and that's having a reliable platform for developers if we don't have that we don't have anything and web developers love the web, right? Well So and so right? There are still a number of issues and challenges that developers come across So we want to be honest about this This is an uplifting talk at the end of the day We want to be honest about this the web does have a problem Working cross browser has historically been really really hard it still has a number of challenges and also with inconsistencies between different browsers interoperability interoperability between different platforms and Devices and all that so we want to make it better for you So we have one joint web platform so that's why we started the predictability project about six months ago and Maybe you've been working with square wheels so far But we see this as our responsibility to make sure this is actually good for you and expected you could spend the time on the right areas and We put our most neutral people working on that So I'm Swedish Rick is Canadian So basically you can complain a lot to us and we'll be able to say we're sorry Sort of see the theme here and and actually thinking about the team We have a number of more Swedes and Canadians on it. So this is not that coincidence And the main areas we want to go through today is how chrome is trying to improve predictability for developers all the work We're doing to make things better and well more predictable Also, how we work with other web browsers To make sure it works the same way across the board. This is not just about us This is about the web and how we do things together Having browsers fight against each other. It's just a weight of waste of time the important thing is the web and Finally, it's about how web developers how you can help improve the platform as well Basically, we want the web to just work for developers. That's it and it's it shouldn't be that hard, but there are some challenges around that So there are five main areas where we want to address this First we want to make sure that you fight the platform less, you know less need for browser specific code pass Making sure you don't have to have too many workarounds for regressions basically things that used to work and then three months later It just stops working. You have no idea what happened also trying to get away Diminish or even just completely get rid of all kinds of polyfills and shims and all that just to cover up for Interability, that's not the way it should be We also want to make sure that we don't ship any accidental regressions and when we deprecate features We really want to understand that we do knowing what we're doing and what the cost is for you How will this affect you and not just like yeah, I never liked this API So we want to show you actually know what's gonna happen We also want to be way way more open about Interventions and Rick is gonna cover interventions more later in his part, but basically giving you options to Well solve issues when that happens But to be honest things do fail fast in the world and When it does fail when it's short it's both fast and obvious to you So it's not just a complete surprise every time you have no idea what happens It's also about having quantified data and Sorry analysis to make sure that we know that when we cancel different features we have the numbers to back it up. How is this actually gonna affect developers and Finally just giving you a more coherent platform Making sure that the most commonly used features work really really well together like we want you to feel this passion Right leave it look in their eyes. They love the web Slices carry but still love Okay, and you know working on the web might have been hard historically you might still have some issues But you know moving forward we want you to look back You know when it was hard and just you know laugh it off You're just gonna be happy because working with the web is gonna be a breeze. That's where we're going and To go more into detail about that We have the amazing Rick. Thanks So hopefully that gives you a rough idea of what our vision is for predictability It's it's a big dream. We've got a lot of work to get there But I want to get a bit more concrete for a minute It's always been part of Chrome's mission as you heard Darren say this morning It's always been part of Chrome's mission to make the whole web better not the web shouldn't be just a collection of browsers that kind of behave similarly But we really realized over the past year that we've got more to do here. In fact You know first and foremost we need to collaborate better with the other browser vendors In fact part of the reason this project exists is because we were really inspired seeing how how hard Mozilla and Microsoft were working to make their browsers just work for the websites that you have all have already built rather than Trying to get you to change your websites to make them work on their browsers and even when that required Copying like some buggy non-standard stuff from WebKit and Chrome it sucks that they had to do that But it was inspiring and it made us want to invest more in this space And so there's all sorts of ways that we've been working better over the past year as as a community as a browser vendor community I'm not gonna go into all the details here. It's probably kind of boring for you We're obviously standards are obviously a huge part of this we invest a lot in the standard process We care a lot about standards But it's even the day-to-day of how we do web develop how we do browser development has really changed We're constantly filing bugs in each other's bug trackers. We're constantly like collaborating on shared test suites It's it's a it's a very it's very different than it was a few years ago But I don't think that's too relevant to this audience. I think probably The area you care more about is it's really important that we do a better job of listening to you And honestly, this is why I'm here. I'm hoping this will be the start of a conversation Hopefully somebody will grab me afterwards and complain what what's bothering you about the web what makes the web hard for you and This is important because I think the web is unique in that It's it's the commons. We all own it collectively. No one controls it. It's really a Marketplace of shared ideas that compete against each other and in that kind of environment It's essential that the different players in that ecosystem are talking with each other and understand each other alright, so Typically the best way for you to tell us that we're doing something bad is to file bugs against us For those of you that don't know blink is the engine the web engine underneath chrome opera and Samsung browser And so I'm gonna talk a little bit about blank bugs bugs in our in our web engine Over the past year. We've really invested a lot in bug health here We realized we had a bit of a problem and so now I think we've got a really good process where if you file a bug on us We it first it goes to a qa team that tries to reproduce it They'll engage with you and try to ask some questions and then once we can verify there's a bug there It gets routed directly to an engineering team Pretty much we have complete coverage now of all of our bugs so that there's some team responsible for checking on the Bugs regularly and and trying to prioritize the most important and working with you to get fixes and As a result of that you can see for this over this past year for the first time ever in the history of our project We've consistently closed more bugs than we've opened which it's always a good place to be in Good and here's some stats I just picked September bugs filed in September by you all these were bugs that were filed via our wizards So people that aren't chromium committers there were 300 such bugs filed in September and Already 93% of those have been reproduced and routed to an area. That's what we mean by triage They're on some teams plate to deal with About two-thirds of them have been resolved in some way sometimes this means actually it's not uncommon that we dig in some issue We talked with people and we agree that actually turns out. It's not a bug in chromium It's a bug in a website or a framework or something like that. That's fine Or sometimes it's a duplicate of another issue And and about 16% of the bugs that were filed in September turned into actual fixes that have landed in the code are now Shipping in Chrome and you know we I think there's more to be done here, but I think this is pretty good I think this is a signal that if you file a bug on us There's a good chance that the right people will see it pay attention and something will happen. I think it's worth your time The other signal that's really valuable to us is our stars you can see in our bug tracker system here There's little star next to the issue if you're signed in and you click on that It means that you care about this bug you want to get email updates And we use the number of stars as a really important signal and prioritization. We know it's flawed It could be games. So it's not the only signal. We use obviously But if you if you look at the stats for just the top starred bugs the top 1% in terms of stars We fixed two-thirds which I think is fantastic and that's true for the entire lifetime of the project It's also true if you just look at all the bugs filed in the past year the top 1% two-thirds have been fixed And that's fixed that means it fixes landed right some of these weren't actually bugs or some of them Yeah, we're other things In fact, I'm particularly proud that if we look at the top 60 starred bugs of all time and in chromium for web platform bugs we've fixed nine of them in the past year and Many of these are things that you may care about you'll notice there's two on this list that have three digit bug numbers That means these these bugs were filed the day the chromium project opened in 2008. So we're a little slow getting to them I'm sorry, but we're on top of it now I think we're also getting a lot better at involving all of you and listening to all of you in terms of new API design Google now when we work on new features We will initiate new web platform features in a process that we call incubation That is a process that really emphasizes starting with use cases not starting with the solution starting with you cases and involving web Developers trying to vet that these use cases make sense and that the that the ideas we have for them Solve those use cases and we do all of this in the open via the W3C is wicked group the web incubator community group All of this is on github github.com slash wikig Take a look at the repositories there You know there's an explainer document that describes the problems that we're trying to solve and there's often draft specs And we we love you to involve you file issues. Tell us what you think and then when it comes time for us to ship a new API this is a really important time for us because We want to balance like it's our mission to push the web forward, but we want to push the whole web forward So the most important signal for us here is what's the interop risk? What's the risk that we're going to regret shipping this because it's going to end up being a chrome only thing We don't want to add chrome only things we want to we we're happy to be able to head We're happy to push things hard But we really try to get feedback from the other vendors you can see on our chrome status page here the colors under each of the other browser vendors Represent what signal we've got from them and you can click on those and get links You know in this case position sticky was something that's already shipped in Firefox a prefix version is shipped in webkit and It's on the edge roadmap as priority medium I think meaning that they intend to work on it So that's like a really strong signal position sticky is something that's going to become part of the web everywhere and At this stage we get a ton of feedback from the other browser vendors to Microsoft and Mozilla in particular We do all we discuss this trade-off in public on our blink dev mailing list And and we get you know when they don't like what we're doing we hear about it And we will delay shipping things to try to resolve outstanding issues All right, and then once even before an API ships it'll show up Behind this experimental web platform features flag you can go to chrome flags turn on experimental web platform features and play with the API's that are Coming up. Of course, you know, we've got chrome canary. We now have chrome canary for Android updates Basically daily so you can really try out the bleeding edge stuff file a bug and see how things change day by day All right The third main area where I think we've gotten better over the past year is that we now have better tools and processes for minimizing breaking changes So first of all, how many of you have worked on a site where a new stable version of chrome has come out? And you've had a big emergency because something's broken on your site and you got to got to do something about it Come on. Don't be shy All right. Okay, not quite as depressing as I feared I'm sorry. I apologize. We definitely don't want to do that But I can't promise that we're never going to do it because it's fundamentally incompatible with our goal of pushing the web forward The only way to never break anything is to not move and so we're trying to kind of be thoughtful and strike a good trade-off here And in particular, I think we've gotten a lot better at Minimizing those cases. Let me give you some examples. This is a specific example That's pretty recent that I think highlights how things should go when they're working well so this was in September a developer noticed that they were they were just using chrome dev channel and they noticed that on their site their input type Equals range element wasn't behaving correctly and they actually figured out that it had to do with Particularly our CSP rule they're using that if they hadn't figured out that would have been fine in this case because the most important thing Is when they filed the issue? They told us that it was a regression that it used to work in chrome 53 And that was an important signal for our qa team the qa team said okay great We're gonna go do a bisect that means we're gonna Binary search through all chromium builds between chrome 53 and then and identify the single commit that broke this website And you see that happened within a day the next day qa team had done that and they had identified one particular chromium commit Which is great. It means that we can make progress on this issue right away We know who to assign it to the developer that landed the change and we know one possible fix is to river that change So this cuts out a lot of the uncertainty that we used to have in our Regression process because we don't have to try to point fingers and do a whole bunch of debugging to figure out why your site's broken So in this particular case what this meant was the bug was introduced back in August and no one noticed for for almost a month And then after chrome 54 beta was released this developer filed the bug within two days A fix had landed for it within a few more days There was a new beta release or chrome 54 that had the fix and by the time chrome 54 hit stable The fix was in there, so it didn't affect any users. This is how we want to see regressions happen And this is fairly typical these days So if we take a look those bug stats I posted before and extend to look just at regressions You'll see the numbers are even more promising hundred percent of the regressions that were filed this September have been triaged 85 have been resolved and 40 percent pretty much have had a fix landed All right, but unfortunately breaking changes aren't just about accidental regressions We believe that it's important in order for the web to be able to move forward We believe it's important that there's some way to to shed the mistakes of the past But this is something that we want to do very carefully and and very thoughtfully we take it very seriously We don't really don't want to break websites as a result of this Try to balance what's best for the platform overall Let me give you a concrete example Any time we're thinking about maybe we should take some break some functionality intentionally in the web The first thing we do is collect a bunch of data. So in this case the security team made an argument to us. They said look Geolocation API returns precise position when users say yes to that on HTTP We don't think they really understand that they're not saying yes I want the site to know where they are where I am they're saying yes I want everybody that's sniffing to the network traffic to know where I am and we know that's often a fair number of people so They argued that we should make geolocation behave as if the user always clicked reject if you weren't on an encrypted connection And so it's okay. Well, let's look at the stats So if you've opted in to anonymous data collection in Chrome Then we send this anonymous data back to Google that we can look at and we saw that 90% of geolocation was already being done over HTTPS and the remaining 10% accounted for about 0.05% of page views This is still higher than what we'd normally like to see if we're really gonna break something But weighing the trade-offs we weigh the trade-offs in public again on our blink dev list We solicit feedback from various parties and in this case we decided that yes it was worth the cost to break this scenario and so we have a Console warning and dev tools to say warning you're relying on something that's gonna stop working We're working on a new API so you can get this from the wild rather than just having to use dev tools Normally these days this will always include a milestone and a date for when it's actually scheduled for removal But then after some period of time that there's been a warning and we've got a blog post explaining that there's gonna be a breaking change We'll eventually rip it out and then we go through our normal launch process, right? We've got canary dev beta stable and if we see that there's a bunch of complaints, but things not working We can reevaluate reconsider before it hits stable and affects a bunch of users All right, so it's still really hard to build a website that provides a great user experience Well also being built out of components that you don't necessarily control iframes Add networks third-party scripts There's a fundamental tension there and if you think about this. This isn't new Browser vendors have always made a trade-off the browser is a user agent, right? It's designed to mediate between developers and users and sometimes act on the user's behalf most classic example is pop-up lockers I mean all browsers have some heuristics in them to decide when am I gonna allow a window door to open to succeed And when am I gonna say none that you can't do that story that's gonna piss off the user and This is a really tricky trade-off We've always struggled with this because on the one hand we want the platform to be predictable We want you to be able to reason about what's gonna happen, but finding the right trade-off for these sorts of things is tough So over the past year, we've gotten a lot more disciplined about how we approach these types of difficult trade-offs We formalize the concept into a term intervention an intervention is something that minimally breaks existing behavior in the browser in order to get some Substantial user benefit and good interventions should be predictable meaning that you can know when it's gonna happen It's something that we could standardize. We will be on a track. Hopefully to eventually be standardized It's avoidable, which means if you're following best practices like using HTTPS for anything That's privacy sensitive then you won't be impacted at all It's only really for things that we consider legacy. It's transparent which means that there's API so you can measure and understand how often you're being impacted by an intervention in the wild and Critically, it's justified by data We're constantly collecting data from the field to evaluate the cost benefit trade-off of interventions and try to strike the right balance for the overall health of the web Let me give you a concrete example In in Chrome 52 we shipped an intervention called Where we throttled the rendering pipeline for off-screen cross-origin iframes Basically what we realized is there was a lot of sites that we're using a lot of CPU for updating animations of ads that weren't even visible And I'm like well, that's silly But you know that was how the web was designed defined to behave like request animations frame is supposed to fire whether or not Your iframe is visible So we did a bunch of investigation and looked at what some other browsers had done in this space And we we shipped an intervention in 52 that showed substantial power improvements on a bunch of sites If you just leave the page sitting there power usage went down by 50 percent in some cases 90 percent And this was kind of an ideal intervention in that when we shipped it To this day we haven't had a single report of any site being broken by this It was theoretically possible that something could have been but this was a great example We saw a huge user benefit For very little cost and there's really a theme here. Thanks There's a theme that We're trying to do more to protect the top document the main application from iframes that might not be well behaved For example, we're trying to extend this to also include timers So set timeout doesn't fire we found a couple cases of that spraking or we're working with people and trying to mitigate that before we We ship that Again, we're designing all of this in public. We think it's important. This is about the web which nobody owns And so we think it's important to have the have these trade-offs be public discussions Again, we do it via the w3c's wicked community group There's a repository called interventions where each of these ideas we have this filed as an issue And we'd love your feedback on them in particular if you've got a concrete example of where your site is being impacted Maybe it's a scenario. We didn't anticipate maybe there's a way we can change the design So we can get all the benefits without actually hurting your site. Anyway So we'd love your feedback here or just file bugs on chrome again All right back to robert Hey, what happened to amazing? I called you amazing. Sorry, we rehearsed it Well, okay So back to the high level guy, I guess So of course part of predictability is also working with developer feedback and listening to you And the three main areas are of course hearing what you have to say and acknowledge the issues that you're facing Also understanding different challenges that you have And finally also getting information from you getting data getting use cases and all that to make things better And one part has been improving the bug wizard for chromium So, you know q another stock photo or bugs But the general idea has just been to with the bug wizard to make sure that it has a very clear web developed focus right now And also that if you file a bug we can have a direct routing to that team fixing that specific issue So the way it looks now you would come in and you would take web developer And it's a very clear view from you would have a few choices that are just relevant to you And then you can sort of dig deeper or describe your case or something like that Whereas before it was a long list where most of if not all of these were completely irrelevant to you So we're just trying to make it slightly easier for you to go through that path We also want to talk about Services like browser stack We can quickly get screenshots from money many different browsers and devices even those that you don't have but just to see what it's like across the board So for instance, you can test your stuff and you can see what it looks like in ie 11 And then comparing and seeing with opera 12.15. This is the same experience and then you know What about the iphone 6 does it work there as well? It's just a really easy way to at least get an impression and a perspective of what it should be across the board Also, interestingly, they offer the way the way that you can use your browser interactively So you can pick one in a list and you can go in and you can try safari or chrome on ios For instance, and you can see what it's like in there as well So services like browser stack and sauce labs and other ones. We really recommend checking those out to to get a good overview And we can't stress this enough filing a good bug or starring or contributing to an assisting one Uh, it's definitely the fastest way to get an issue fixed so we can resolve the the challenges that you're facing And also as part of this in our website, we're launching a new feedback section Where we will surface a number of ways for you to well give feedback And also getting involved earlier on and and try out new different things as well Because Engineering for well basically any browser is being handled by bugs It could be things that aren't working or feature requests or something like that And we also want to to teach you or help you in how to file a good bug So there's also information here how you best describe your issue to make sure that it gets resolved And also how you can create a minimized test case and then host it somewhere so you can share it with us So we also want to foster discussion We want you to be able to talk with each other because you never wanted to be like, you know The poor Denver coder that disappeared and was never found again So the main idea here and we have some information on the feedback section It's just about you know share information It helps people or share the issue that you're facing because you know being silent on your own and upset won't help anyone So so please take part and contribute And also as rick was talking about like many of the bugs they're being filed is by our own engineers or between different browser engines And since everything within development is still driven by bugs We wanted to make it way way easier for you to find bugs and and Seeing what it looks like at the same time we want to present the web as one joint platform We don't want to just be able to or having to hunt down Every bug in every tracker everywhere. So wouldn't present it in one joint interface So I started thinking about this how we could do that and and we're google so we kind of liked the idea of searching for stuff and also getting it in in one interface So I presented my ideas to eric bitleman on the team And sort of describe what I wanted. He had a few questions for me And then he started hacking so he created something that we officially nicknamed the bbs Which is the browser bug surger and when I saw it it was bliss. It was fantastic And it was just the way it should be So as part of the new feedback site We now have the browser bug surger as well We got good help and input from other browser vendors as well How to interact with their browser bug trackers and getting information from them as well And why it's so important to search for existing bugs is that last month alone with blink 25 percent of the bugs being filed were duplicates So please please search before you file something But with that said it's always better to file a bug than to not file a bug So if it's a duplicate, it's not the end of the world. It's make sure to share information So This is a shiny slide. Do you want to see a demo? So we'll we'll try and do a shaky demo What don't don't clap yet I appreciate it, but no So Would we get this here? Nope, is that you? Uh, yes Perfect. Thank you. I also like they were kind enough to make the cursor really really big for me here Uh, could we get it? I have a nice view here at least So the idea is that you would go in here into the the new feedback section of the website and you would have this Field and then you can immediately start searching for something And what you get presented with is a list of bugs across all bug trackers So both where they are being reported, you know across webkit chromium And also masala and edge as well. So basically all the major one web browsers You can also see the current state of these bugs are the are they being resolved won't fix are they just being New and filed or something like that. It's just a really really quick way to get an overview. What's happening? and you can also easily Page between different results here Or you can choose to see all the results And also in this separate page, for instance, if you want to fill filter only on A couple of trackers you can do that as well and just compare those as well or just Fade out fixed issues. So you only find the actual relevant ones that are still working, right? This is pretty cool, right? Now you can clap. So we had a little backup video in case, you know And also, we want to say tomorrow afternoon at 4 p.m We're going to have a breakout session about web predictability And it's the only session with the the welcoming of come there and complain as much as you like Okay, come in and why and come and tell us about your biggest issue Because we need to fix this. We need to make this as good as possible for you So Summarizing all this we are really trying to treat the web as one single platform the way it should be It's just one big platform for you and should work across the board It doesn't matter for you if things Only work in one place and not the other one and or which browser is doing right or less, right? It has to work across the board So also, please keep on testing on beta releases file bugs star bugs for features So we know what you're interested in or need help Go and visit the new feedback section try out the amazing browser bug searcher as well And finally get involved. This is this is your web And we want to end on a note of saying thank you The web would be nothing without you. We're doing this for you So you can create all the amazing experiences for people out there And I think now in these times more than ever We need one big joint inclusive platform for everyone. Thank you