 Okay, the next talk is about the start of the schedule. It needs to be a one hour long talk. Steve has decided he's playing that time so it's going to be half and half. First off, we have Nicolás. He's the one developer we're going to be going to partner with those dev tools. Mostly on the console, although that's only for one or more people to know. He's going to give you a tour of the partner's dev tools. I'm going to leave you to it. Enjoy. Thank you. Do you hear me well? Yeah. Okay. So, hello everyone. I'm Nicolás Chabob. I'm a member of the Firefox DevTools team and I'm working on the console for about two years now and a bit less than a year as a Mozilla employee. So today I will talk to you about what the Firefox DevTools and what we added in 2017. So the DevTools team is rather small, about 15 people spread across your world and North America. And what we have been up to in last year. So basically a lot and I will try to not just have a dumb list of new features and that will make you fall asleep at this hour. So we have this website. We use to send contributors to when they want to work on the DevTools. It shows you the list of the bugs we have on the DevTools and you can filter them by tools and pick if this is a good first bug to work on and or if they are a month or two work on this bug. So there are a few issues on this site which I want to fix using the Firefox DevTools and so at the same time we'll show you a feature we added last year. So let's start with the design of this site choosing the inspector. First thing you notice when you inspect the inspector you when you open the inspector is the new queries. So it's a bit hard to spot here but we added the new photon design system which is the design system Firefox use for Firefox UI. So the first issue I have is on this page I have a list of unordered links and I do have some space between my lives and I just know why because I didn't have any padding or margin. And so when you open the inspector you can see that there is a little button with a dot inside which means it's a white space on the text node which takes 3.54 pixel. So it might be interesting when you're designing something to know what there is some space between elements and if you want to know why there is white space node basically it's the way you hold sorry or HTML code you can read Patrick Brossett's post about it. Another thing that bother me here is the look at the animation. So you can see the Firefox logo spinning when we are searching for lists of that. We are rotating it and it's a bit linear. And so maybe we can do things better. So to work on the animation first I need to trigger it. So I can do this in the UI but just trying to select a tool and see the logo spin but it's a bit limited since when the bugs are coming the animation stop. So I need to find a way to add the loading class to the body which triggers the animation. So there is a button in the rules view which is really hard to spot here but it's the dot CLS button and when you click on it you will have an input where you can add a class and then it put it in a toggle with a checkbox behind it and you can toggle it and see the difference between loading and not loading. And this is not just limited to only one class. You can have multiple ones. So in this page we have a dark mode and by doing that you can see how the dark and light mode looks like with the animation or not. So let's go back to the animation. I made some changes tweaking the rules and now I have two properties animated which is transform scale and opacity with different easing. So you can see the curves looks differently because they don't have the same easing function. And I can hover those curves to see the animation properties or I can hover a specific key frame. So you see the little circles in the bottom. If you hover them you can see the property at this given time in the animation. So the animation looks fine to me now. Let's move to something else. Another issue I see on this page is it could be better for first time contributors. We used to send people here and say, okay, find the bug but it's a bit weird. We have some links at the top to say, okay, how to install Firefox and build it, stuff like that but it could be better. So maybe we can try to have a landing page for first time contributors and so they have a better sense of what the page is about. So here I just built an unfiled landing page and we are going to set up some rules using the inspector to make it better. So first we want to have a nice branded gradient colors. So I have these CSS custom properties which are extracted from the photo design system. See dash dash blue 50 and so on. So I can go to the world view and type my gradient like linear or gradient and parenthesis and then dash dash and it will automatically give me a list of all the different variables I set in my page which is quite nice. And then I can hover a specific variable in my world view to see what its value is. So here I can know that dash dash white is white. Very helpful. For more branded look, I wanted to use the Zilla font on this page. So Zilla is the font that is used on the new Mozilla logo and something that landed just a few weeks ago on the inspector is that the font that is being used on a given element is underlined. So here we can see the Zilla font is underlined which means it's the font you are being served. And it's really nice so you can spot if you are missing a font, it's not installed on your computer or if a remote font wasn't able to be downloaded for example. Which makes me think you can go to the font panel and check the font properties and you can even enter custom text to see what the font looks like. Like here I just put Firefox files for good. And so this is the system font which means a font that is installed on my computer. But if you have a remote font you can see other properties like the font page declaration. So now let's get to the bigger part of the inspector this year. CSS Grid is a set of new properties that lets you declare a much simpler way that we used to. If you are not familiar with it you can check the work of Jen Simons, Rachel Andrews, and Wesbos, Justin MFU who put terrific resources online to learn CSS Grid. And by the way, a whole my slide are built using CSS Grid. So I want to use it as well for my landing page. So let's put display Grid on the container and then you can see there's a little button next to it or you should see it. And when it's clicked it shows the boundaries of my Grid elements. It's hard to spot now, but then I can change the color of these boundaries and put it on white for example so it might be more noticeable. Yeah, not so much, but you can see some lines and it's all about the boundaries of your Grid. Then I'm going to share a little secret review. We are working on the wait for free panels at the same time on the inspector. This way you can see and set things even more easily. So here I opened the third panel and I can see both my rows where I will put my Grid properties and the layout panel where the actual layout of my Grid is. So I can declare a simple template of four columns. So it's grid dash template dash columns and then some syntax we don't have to learn now. But then you can see both the contents and the layout panel are updated in real time. And in the layout panel I can hover those columns and it's highlighted directly in the content page as well. So you can spot where your things are. And then I can just play with my element and place them in the Grid. So you see those little kind of buttons on the content page? It's the column and lines number. So when I'm on an element I can then place it using those line as references. For example my title I put it starting at the first column and ending at the minus one column which is the last one. And I can do the same with the other element. So the logo I just put it in the second column which is now is good. And the links that are on the right I want them at the bottom. So it's nice. And I just placed something I saw on internet for using a Flexbox property that's looking nice. And if you are like me and are confused by Flexbox we are also working on the Flexbox Inspector so you might be able to see it during this year. One last nice trick in the Grid Inspector. In my CSS I declare some areas. So I can name areas instead of dealing with line and column numbers. And so there is a little checkbox in the UI which I display area names. And when clicked you can see names are dialect in the contact page and you can see which cells as which name. So things are going pretty good I think but we can do even better. So there's an experimental properties called shape outside which lets you define non-boxy shape for content to float against. So basically here I have a float div with a shape outside set to circle and then I have a little button next to it. And if I click it it will show me the shape, the circle shape and then I can move it. So the video is over but there is a circle and I can move it around or grow it and you see the content flowing at the same time as I manipulate the circle. It's pretty red. And there are other types of shapes like polygons and we do have a shape editor as well so you can add points and move them and see the content flow across the screen. Okay so I think we have a good landing page now. So what's next? I heard there was a small library, it's called React, made by a small company. So I want to try it out on this page and because we are building something with JavaScript I think we have to use the debugger. So last year we shipped a new debugger using React and Redux which allows us to iterate quickly and also have lots of contributions because people are used to use those technologies. So something in my page is not working. I can't have the list of bugs loading for some reason and I don't know why. So I opened the debugger and it may be lost because I don't know what to look after. And there is a little button which is the question mark when clicked show me the shortcuts on the app. And it tells me I can do command p to search for file so okay let's do that. But then I remember I don't know which file to look at so maybe let's try something else. I know something is wrong with an input because it's when I click the input that something must be loaded. I tried to search the entire project for input and I got this nice view of all the input iteration like in sublime or in DS code. But there is multiple of them and I don't know what we're trying to choose. So another way to see what's happening for events is to look at the inspector and spot the event bubbles on nodes. So here I choose I inspect the input and I see a little icon and one click I can see there is multiple events attached to it like. And the one I'm looking for is unchanged and I can then jump to the debugger using that. Okay, I'm now in the debugger, that's cool. Looking at the right file, maybe not in the screenshot but I am. And I can see a nice source tree. We used to have only a list of scripts in the old debugger which was really hard to navigate. Now it's really a nice tree and you can even see that we are using source map and we have the big bundle file but everything is shown in the web pack to show the original files and original paths. So I can navigate like I do in my editor for example. And you can also collapse things and expand and directory. All that click will expand the whole directory. It's pretty nice. And now that I'm in this file I can have a look at the outline view. So in the left I can see there is a class which is component sidebar and a list of function. And when I click on the function I can navigate to it in the debugger which is cool to just navigate through a file. This one is pretty small but you can have huge file and it's very helpful. By the way, it's maybe hard to notice from your state but do you see how nice the code looks? It's like I used JSX and it's all highlighted and nice and feeling very crisp. It also work on TypeScript, CoffeeScript and even C files. We used to highlight everything basically. And when working with source map files I can just jump to the generated location so I can look how my code is being generated in this huge file of more than 20,000 lines. Okay back to the faulty function. So I set up a breakpoint in it. I selected a tool and now we are paused in the debugger. And I can see the stack trace on the right which is quite nice because all the React calls are groups into a single items and I can expand it if I need to see React internals but most of the time I don't care about what React is doing. So they are nicely grouped. It's not only for React, we do it for Redux as well and Immutable and other libraries we support like maybe 20 of them. Another nice thing is that even if I'm in an original file and the even variable has been renamed to E I can still evaluate even in the watched expression and access properties on it. So I'm not restricted by source map having renamed my file. So basically when you debug something it involves a lot of clicking on step in, step out, step over button to get to the actual point where you see the line you're interested in and it might become person. So now you can click on the gutter on the line you're interested to go to when you are paused and select continue to here. So it will jump to directly to the expression you wanted to go to if it's in the right path. So I know what was the problem on my function. Basically it was this isn't defined and it's because React asked you to bind all your methods. So it can work properly with events. So here I just bound my methods in a constructor and do you notice what happened? It's like I reloaded and breakpoint was on line 14 and when I reload it's on line 18. And I did not do anything for that. So that's because we have something in the debugger called AST breakpoints. So breakpoint is not located anymore just on a simple file plus line number. It's sorry. It's referenced also by an AST location which means here in this case it's the variable, the search bug variable assignment in the uncomponent change method. So when you reload we try to spot that very specific instruction and not just a line number. It's very nice so when you iterate over your code and try to fix bug you don't have to deal your breakpoints on or see the breakpoint being on a totally wrong place and pause when you don't want it to pause. And I tried to integrate wasm on this website but I felt short of ideas. So I just put a nice picture of C, Fibonacci function running in the browser and it's nicely formatted and highlighted and you can even pause on it. We also have rest support I think but we don't have highlighter for now so didn't show it. So finally fix my react bug. Right. So one thing that I want to fix now is the Contributals list. So on the right you can see there is a list of people. This is the list of people who fixed the bug on bugzilla during the last 30 days while not on the staff. But we also have code which are not on the Mozilla central repo. We do have repository on GitHub and are the DevTools HTML organization. So maybe it would be nice to see contributors to these repos show up here also. So I made a call to the GitHub API to get all the repos we have for the DevTools HTML organization. And I get something back but I don't really know how to operate from this point. So let's see what we can do with the console to better understand why I can do this data. This year we also shipped a new console with cleaner design so you can really focus on the logs. Yep, sorry. And it has the same colors as the rest of the DevTools which are pretty nice. You can also see that the first log option has been moved to the UI. So if you click it, when you reload the page you won't see your logs disappear. So previously I had filtered off error messages. I don't really know why but. And you can see the UI that tells me that some messages were hidden and there's a UI that a button that can click and which will reset the filters to the default state. Which could have been helpful when digging my React bug because here I see an error message taking me to the correct JSX file so all the stack trace is nicely source mapped. And there is even a long molding which will take me to the MDN page so I can have a better sense of what the river is. And since we are in the console, I can see I added Redux logger to my page so basically when you're using Redux it spawns all the action you fire in a nice way. And it looks nice and it's because of two things we added in the console last year which is console.group. They were already supported but you couldn't collapse a group which was making them almost useless. Now you can expand and collect them as you wish and this allows us to support console.group collapsed as well which creates a group that started collapsed by default like the big group you can see in the image. The second thing we added was style console.group. So we already had a style console.group but not for group. This is now fixed. And if you don't know style console.log it's a nice little thing that lets you set parts of your messages like style parts of the machine and using CSS properties. So here we have console.log, person C, hello, person C world and color red and color blue. And basically it will output a red hello and a blue world which is nice. And you can build fun little helpers like I did to have a rainbow loss in your console because we all need this. So I made the call to the GitHub API to get all the repos on the DevTools HTML org. I posed the debugger when the extra call was over so I can expect what was written to me in the JS results variable. The first thing you may notice is that you can expect the object directly in the output. So yeah, like Chrome does but we are also working on the console sidebar so you can pin an object to the right and still see your messaging coming into the console. So the results I get from this API call is pretty big so maybe I want to try to use console.table on it. Basically console.table puts a nice little table on the output if you are using it on a large object or an array, a map, a set. And it shows in a nice way in the console but this is still not ideal for my needs. And usually what I do when I have to deal with large amount of JSON data, I just copy it and then display it in my editor. So you can copy an object right into the console by doing right click on an object and then copy object. It will try to JSON stringify it if it can. If they are not proto or feel like that. Then you can paste it where you want. Very helpful. And since we are talking about some API function, you can see a recap of all the APIs we have. So you know probably console.tag but there's also console.arrow, console.warn, console.info, console.debug. There are different level of log that you can filter in the console output. And then we talk to, there is console.dear of an object. It will auto expand the object in the console. We talked about console.group, console.time and we'll tell you how much time was spent between those two calls. So you can measure a function called how much time a console, a function called was taking. Console.count will output an incremented counter each time it is called. So it might be helpful in a console to know how much time it is called. Console.arther takes an assertion and then a message and will only output something into the console if the assertion is false. Like basically a test in your console. And console.cleared just cleared the output. And yeah, I have some little tricks that might be helpful. So when you are in the console input, you can type inspect on the variable and it's basically an IDS for console.dear, bit shorter. You can concatenate multiple parts of a message like console.logA, the variable A, comma B, the variable B. So you will have A and its value. Or you can use the ES6 short hand which is you declaring a small object will have A and D properties and E and D values which is very helpful to spot which variable, which one. And you can use console.log in conditional breakpoint in the debugger. So if you right click in a gutter on the debugger in a conditional breakpoint and type console.log, you're viable in it. The console.log will be executed but since it returns and defined, it won't pause the debugger. So if you don't have access to the source for example or if you don't want to add another console.log, you can do it in the debugger and it will show up in your console but it won't pause the debugger. Okay, one last thing I wanted to show you in the console is that we can display network logs as well. So you have to enable the filter, the XHR or request filters and basically we show the same components with the net monitor. So you should have a consistent experience between those two tools. And here in the console, you can even take on the status code. So here you can see a green 200 status code and if you click on it, it will navigate you to the MDN page with the 200 code and explain to you what it is. Okay, so I saw the XHR code to GitHub and let's switch to the net monitor to fully inspect it. The net monitor was also rewritten in React and Redux and have these nice photon colors. There were some improvements in the UI so you can directly persist log and disable the catch write into the net monitor. When you click on the network country, you get to a panel we call the details panel where you can inspect more deeply a network hall. So here we can see all the request and response headers and you can even click the question mark icon behind them if they have some and it will take you to an MDN page explaining you what the header is which is really, really helpful. You can also go to the stack trace panel which shows you the stack trace that led to this call. So if you have a fetch call that do a network call, you can trace it and it's nicely source map and here on the stack trace, I can see my accent.js file being called and I know I can have a look at that if I want to see why the call was triggered. And in the net monitor, if you already found something, the log that you were looking for, you can pause the net monitor. So you won't show up. It won't show you any more network logs happening. The network logs will still happen. The browser will still make the network logs but they won't show up in the UI. So you can concentrate on what you are looking for. So here on to inspect my GitHub call but maybe have a huge list of requests and I don't know how to spot it. So what I can do is use the filter input to filter in the specific domain. So if I type domain column, you can see already auto-completed with two domains like the different domains I have in my log which are github.com and bugzilla.com.org. And I can also filter by negative filter. So I can type minus domain column and this might be helpful for tracking third parties called like if you're on the news site and want to see all those nasty ad trackers, you can do that with negative domain. And you still have issues and you much want you can combine multiple filters. Like I want the github.com domain calls and made by fetch, for example. So you can type cause fetch. So I found what I was looking for and I can check the parameters of these network calls. So you can see that repeated parameters are nicely grouped. So here you can see the components, for example. There are multiple of them but they are grouped under a single node which is quite handy. And the most important thing for me is the response panel. Since the response has a proper content type header, I can directly inspect it as in the console which is really helpful. And doing this I wonder how many repos the Mozilla organization and github had. So I used the edit and resend features which allow you to modify the URLs and the parameters and resend a new request. So we had just changed the DevTools HTML organization to the Mozilla one. And I was able to see all the Mozilla repos on github. Which looks interesting but there are quite a few of them. So let's open the request in the new tab. You can do that by clicking on the log entry and clicking on the open and new tab. And it takes us to the JSON viewer. This view is activated when you try to inspect a page with a content type, a JSON content type basically. It should have the same themes as you define in your DevTools settings so you don't strain your eyes if you are used to a dot sim background. The nice thing, especially when dealing with github APIs, is since that links are automatically transformed into actual HTML links, I can navigate through endpoints. So here I can inspect this on Bony repo and see what it's about. Okay, that's it. Well, almost, sorry Julien. I want to highlight a few things that were not made by the DevTools team but that can help developers doing their jobs. First is web extension support. Daniel Lee talked about it. The web extension team did a great work and most of the Chrome extension in the DevTools work also in the Firefox DevTools. So you can have React or read us our Angular DevTools right into Firefox basically for free. So here's the website I was switching to React with the React DevTools. Second thing is Firefox screenshot. Daniel Lee talked about it also. It's baked in Firefox and you can copy things directly the image I have into your clipboard and then paste it into Slack or Sketch so you don't have a huge number of temporary files on your desktop. And the last thing, it's multi-icon containers. It can be very handy for developers because if you want to inspect multiple roles on a given web application, you don't have to log out and log in again with a different user. And you can have multiple containers for, for example, a simple user role and an admin role and stuff like that running in the same browser side to side. Super helpful. So this time it's really it. Thanks a lot. Listening to me while being hungry, I know it's difficult. Please come and see us today. Tell us about your bugs on the DevTools or your IDs. Lots of things were added because some contributors, some people went to us and say, hey, it would be right if, dash, dash, we don't know what all the, the different cases you are experiencing everyday are. So you can also reach us on Mozilla RDRC on Slack and just go on Twitter. Thanks. Does anyone have some questions or requests? Well, this morning, it works. See, no, it's here. Good. You're all set. I'm all set. Yeah, I think so, yeah. I think we can start maybe now. The console and the network and all that goodness. And Julien is going to talk about perfect HTML and the perfect spectrum. I'm going to leave you with that. I'm very happy that you're here at lunchtime. It's probably hard on you for your stomach, but hello. So today we will talk about, with you about the HTML, which is a profiler. I need to speak less loud, maybe. Okay. I'll talk about the gecko profiler that profiler is inside Firefox. We'll get into more detail. So me, where is my data? Okay. You don't have any information about me. That's okay. So that's me with cool glasses. I'm in Mozilla for one year, for five years and I work on the profiler for one year. Probably adjusted to the French accent already with Nicholas. So today I'll explain to you what is a sampling profiler. So that's what the gecko profiler is. And we'll dive a little bit into details about what our code is, what is a timeline, what are markers, and maybe if we have some time, we can try to analyze some profiles. So first, the sampling profiler. Sampling profiler is something inside Firefox that stops your Firefox every millisecond or the interval you can configure it, but one millisecond by default and look at the stack. The stack is the order of function that we're called to at this specific moment in time. So we do that for every thread and every processes. And then we can capture all this measurement to merge it into a profile that we can analyze. And we merge the stacks into a code tree. So that's a little bit of jargon words that we, technical words that we use, but that's very important to understand. So maybe a quick example for you. Here you can see there is the function A at the end that we call directly. The function A at the top call B. The function B called C. The function C could call do work and do work does very useful work. That is a loop that takes a very long time just for the example. So what happens is that every millisecond we look at the stack, can you see that correctly? Yes, we look at the stack. So here every millisecond is the same stack because it's a simple example. And first millisecond we have A that call B that call C that call do work and the same for everything, for every millisecond. And we merge that into a code tree. So the code tree say that A, B, C do work and we can see on the right the actual time that is spent inside this function. So running time is the time spent in this function and self-time is the time spent by this function. So we can say A, B, C and C do nothing actually. They're just called do work. So that's why running time is zero millisecond but we have to spend time inside all these functions. So we spend six millisecond in them. But the last one do work, there it's self-time is six milliseconds. It means that the actual work is happening there. In the profiler, it looks like it. So on the top you have the timeline. Here there is not much. There is only one stack. But you can see a tree. That's how we display the code tree. And so the first line is the actual HTML file because it's where everything starts, right? We start on the web, we start on the global scope. We call A then which could be, which could see, which could do work. And on the left you see the actual time that was, that happened when I run it. So it was 94 milliseconds here and you can see that do work. For do work the self is 94 but all the others it was zero. So that was a very, very simple example. So what happens if we take another example? So here I have A, B, C. C has a loop that called do nothing and do nothing actually does nothing, right? So what happens here? Every millisecond we will look at what the stack is. So it's A, B, C, do nothing, okay? But actually in the code tree we don't see do nothing. What happens here? What happens is that because we sample only every millisecond, actually when we call do nothing it's between these milliseconds. The actual work is actually in C because that's where the loop is. So that's a fundamental problem with a sampling profiler. We miss data. So sometimes you get a code tree and you see okay I don't see this function, why? Because it just happens very briefly. Even if you call it a lot, if you do nothing in it or if it takes very less than one millisecond you might miss it. That's something that you need to keep in mind when you analyze a profiler. But here there is something slightly different. Here I'm doing work both in C and in do work, okay? So we get the same thing, the same code tree but the running time, no, the running time are the same. So in reality what happened here for C, the step time was maybe one or two milliseconds. We still spend some time in that function but the most time is actually doing do work. But we actually have the same code tree as in the first example even if the code was slightly different. The difference was that do work was called several times, okay, but we still see it only once because what we do is we merge the code stack. It's not because you see a function once that it's been called once. It can be called a lot of times. What happens is you get the same code stack so we merge that in one code stack so that it's easier to analyze. You follow me? It's okay. It's very simple in this instance, I'm very complex. So more complex code now. Don't pay attention to the highlighted line yet. It will be for later. It's more complex. It's just more function calling, more functions. And what's especially interesting here is that the function f, I think, the function f, yeah, the function f is called in two different places. It's called in C at the top. It's also called in H at the bottom. And f itself calls G, okay? And f and G both have very expensive loops and E as well. So the goal is to show you what happens when you call the same functions in different ways with a different code stack actually. So we have, so it's very short here but you get the idea of three samples every millisecond. So every time a different code stack. First time A, B, C, D, E. I can come back here. A equals B, B equals C first. C equals D first. D equals E. And then C will call f. So that's what we see here. Second stack is A, B, C, F, G. Okay? And the third stack we have is A, B, H, F, G because B equals H, H equals F and F equals G. So we have three different stacks, okay? Because that's our code. And so what we do is we, again, we merge the stacks together but of course here we have a more complex trees because, yeah, because that's how code is. So to make sense of this code, we get the code tree that is on the right and in the perf tool we get something like that. We have the same tree in a tree light structure. And it was something interesting. So you remember the highlighted line? It was F and you can see that F has a self time of 66 milliseconds here while it's running time is 135. It means we spent half of the time in F also doing something. And then we spend half of the time coding something else that does other work. So yeah, that's basically what the code tree is. It's a representation of how your code runs and in a way that makes it easier to analyze. So here it's already ordered actually. It's already ordered in the order of the functions that take the most time. You can see on the running time left it's roughly ordered already. So when you see a line of A that code, what do we have here? B equals C and H. C, we spend the most time in C and then in H. It doesn't mean we code C first and then H. It just means that C was more important. So we have a tree that is already ordered by the time we spent in functions. And we have another tool to help with that because here it's ordered from the top but we can also invert. Invert means we look from the bottom of the stack. And here we see that G is actually the function where we spend the most time. We spend 138 milliseconds on G itself. But G, if you remember, here, G is code in two different places. It's called, you have it in the middle here and you have it at the bottom. It's code in two different places. So it's difficult from this view to see what is the most expensive function. But once we look it from the other side and we merge it differently, we can see that actually we spend the most time in G. It doesn't mean we spend the most time in G once. It can be different times. But that's probably a place where you would like to optimize your code because that's a place where we spend a lot of time. That's why it's also a bit of note. It's sometimes difficult to analyze the profile for some code that you don't know. Like if you run it on Twitter, you will get some code that is obviously obfuscated. And it's difficult to make a sense of the code if you don't know the source code. So it's best if you work it on your code that where you have the source code you can look it because it just shows you measurements. It doesn't show you how the code is actually code. For that, you need to use a debugger or things like that. If you know your source code, that's where you... That's useful to analyze your own source code. Okay. So finish with the code tree. I can stay a little bit on that. How much time do I have? Do I have seven minutes maybe? Okay, roughly. There are more tools in the code tree that we can do. I won't show it into more details today. You can merge functions together. You can... If you have a recursion, you can merge a recursion into only one line. So there are useful things that you can do with this that I won't show up now. The timeline, so the timeline, I will show you an example maybe of a real timeline. How is it? It's there. For example, here, on the third line here. I will maybe zoom in it. Okay. So what's important to know with this timeline? Because it's easy to think that, okay, maybe the CPU usage or the memory usage or I don't know the FPS. It's not like that at all. It just represents the stack. It means that if it's flat, the stack doesn't change. The stack, again, the order of functions you call. But if you have change, changes in this timeline, it means that something happens. So that's where it's important to focus, when there are changes actually, because that's where something happens. When you have long, flat things, it means also that you have, you can have one function that takes a long time. So both are important, actually. Okay. So that's the timeline. Where is my, okay. Marker. Marker is something interesting too. So as I explained earlier, Gecko Profiler is a sampling profiler, but the markers helps overcome the limitations of this because you will instrument your own code. So in Gecko, we do that in C++, of course, but you can do it in your JavaScript code with performance.mark and performance.measure. And you will see that in the profiler. And actually, what I showed you in the example, it's a React thing. In the React development version of React 16, I think in React 15, you need the perf add-on. You will get a lot of markers to show you how your components are rendered. So here we see, so the first time is connect something because we use Redux, and then there is the actual component. So you see the rendering how it works. And I think in React 16, it's even better. And I'm pretty sure that in other frameworks, you have similar things, but I don't know the other. Yeah, so it gives you a sense of what happens in your program because, again, you know it. It gives you a sense of how much time it takes to do something. So for example, here for the first one, you are a manager, it takes a lot of time because, of course, it renders all its children, but it shows you, it points you to the right thing to optimize in your code. And that's the important thing. And in Gecko, we instrumented also the right places. So we know reflows, when there are reflows, that's very important to optimize it. So we know when there are garbage collectors, that's something that can really slow down your code if there are a lot of it. There are DOM events, of course. I shouldn't forget that. And we also generate special markers to show where the event loop is stuck at one point. For example, if I come back to my example here, there is a big red line here that helps me spot where the event loop was not working. So I came back to my full profile, okay? And I can look here, for example, I zoom on it and I can really see what happened during this time where the event loop was completely stuck. Usually, if the event loop is stuck because you do too much JavaScript or your reflow, your reflow is too big because the DOM is complex or you have tables or, I don't know, there are lots of different possibilities for your application to be slow. But that helps you focus exactly on the right spot already. So what's good with markers is that you never miss them. It's not like a sampling thing. It's just that if you put a marker, you will get it in the profile, even if you don't sample at the right place. So that's why it's complementary to the code tree. So maybe now, because we're ending, we're nearly at the end, how do you use it yourself? So there are actually two solutions. First solution is the most supported one because that's the one we use the most at Mozilla. There is a website called perfhtml.io, perf.dashhtml.io, where you can install an add-on. And from this add-on, so you will have an icon. It's a web extension, right? And so web extension, it's very important. It means that we have actually an API to control the gecko profiler. It means you can do web extensions to control the gecko profiler, actually. So that's an aside. And so you can record and capture from this add-on. And the second solution is because we just integrated the new performance panel that you can enable from the settings, the DevTools, you can record directly from the DevTools. So I think there are things that we don't do exactly the same. So the first solution, you will get always a full experience, but with the second thing, you can also do things. If you don't want to install an add-on or... Think like that. I can show you some more analysis. I think two minutes, maybe one. Okay. This one, maybe. Okay. I want my... Oh, is it? Okay, there. That's an example of where you have Android Devs, okay? And we will mutate them. So let's see. So I have my add-on here. I will start it. I click on this to do some work. It's not responsive very much. Probably because some work is happening. It's slow, right? Let's capture. Grabbing the profile. Come on. So it has the right moment that things don't work, right? Okay, there. So we're symbolicating. It means we try to make a sense from the memory address we have and we transfer that into functions and methods. So what interests me in the field? Because at the end is when we capture. So that's very interesting. So let's focus on this. Oh, big red thing in my content. I will show it. What's happened here? What do you think happens? We focus on this here a little more. Maybe look at the marker table, marker chart. Steals, reflows, or there are a lot of reflows here. Maybe the call tree. Look at JavaScript. Maybe I will look at JavaScript only, okay? JavaScript only. There is this function, generate letters that takes some time, but mutate them itself takes like 100%, okay? That's a lot. And when I look at the full thing, so I'm here. So that's what does so easy with this is that it's very targeted to get code developers at the moment. It's not very easy for web developers. So you need to use it a little bit to understand what's important and what's not important for you. And but we plan to collapse better the C++ part so that web developers can see better. Oh, see here, get bounding client rekt that's the one I was looking for because I knew it was there. But there is get bounding client rekt that is probably triggering a reflow. So maybe we can look at the code. Where is it there? Okay. Let's look at the debugger. You don't see much here, right? Hmm, indeed, indeed. We were calling get bounding client rekt after changing something. So it's not very good. So it was a very simple example. I knew what I was looking for. So it was easy. But it's not always easy to analyze profiles. It takes some time to me that is very small. But I hope I gave you the, I gave you some that you wanted to try it now for real. And I'm here if you want some more explanation and some more demos. Thanks to my coworkers, extra extra. And thank you for your attention.