From Friction to Flow: Debugging With Chrome DevTools

Today, I'm going to talk about Chrome DevTools or cars, but I want to focus on the part that I'm most excited about. So, the first thing I want to talk about is how we try to remove the frictions along the debugging journey to make your debugging flow better.

So let me start with a personal story. Perhaps you have similar stories like that. So recently, my partner and I, we moved to a new house. The good thing is they have a garden. The bad thing is they have a garden which the grass grows from time to time. And then, as a lazy person, we wait until the last minute after the grass grows for a certain length. Then we try to, okay, we have to clean the garden now.

So we walk across the garden and we found that we actually have a pair of scissors in the garden to do the job, but we need to do that manually. That still do the work. And then after that, since we newly moved to the house, we vaguely remember that in the cellar, two level dowels in the garage, the landlord actually left us an electronic glass trimmer to do the stuff. And then we are also not sure whether the glass trimmer is there. It's faster, but we are not so sure. So guess which one we choose, the manual one or the automatic one? Yeah. So we choose the manual one because we think that we can live with that. So we decided that it should be just fast, one hour into the process of manually cutting, we finally went down to the cellar and then searched around the messy cellar, and then finally we found it and then we do the job under 10 minutes, done.

So the reason why I tell this story is not to tell you how lazy I am, it's not, but to think about what are the frictions that I can remove between this process of me fighting and then cutting the grass? How we remove the friction from this process in order to prepare for the next trim? If you think of it, DevTools, probably is like your, sometimes it's like your garage, it's like your cellar, two level dowels, we have a lot of these hidden tools that you might sometimes get it, know it from your colleague, but you know when you're really like, have a problem, and you try to debug it, and then you might find that oh, there's this feature, maybe it's too far away, I roughly remember that, sometimes you might be not enough time to do a Google search to get the result and then you just leave it wherever you can, try to debug the thing, and sometimes it's because the tool is really too hidden, or it could be sometimes that you don't know what you don't know. The tool exists, you don't even think about finding it and using that.

So take for an example, inspecting and debugging disappearing elements. So I guess a lot of us have these issues before, like if you're using Daisy UI or any UI that have a pop drop down, sometimes the drop down result or the styling is not correct, you want to sort of inspect the result and do some code changes, or the other one, probably you have a search drop down, like the YouTube one, that you want to inspect on the result and do something on it, or if you are using bootstrap, this is the pop over that has the questions. So let me do the demo now to show you the problem. Oh, by the way, the first slide that I showed just now is a real screenshot that I took from here. You can actually use %c in the console log to pass in your style, to style your message nicely like this. Cool.

Okay. Get back to the disappearing element. So let's say if I click on this dismissable pop over, I want to debug this thing. I want to change the style. So what I will do is that usually I will just click on the inspect icon.

Oh, my browser freeze. Let me just refresh that, do that again. Do that. Okay. Okay. The whole browser freeze. You know, this is doing live demo on the stage. Cool. I will open a new tab on it. Okay. I'm using Chrome Canary, by the way. This is cutting edge. Yeah. That's why that's what cutting edge means. Okay. Let me just open this one. Okay. Cool.

So you want to debug this. If you try to click on this icon and try to inspect it, you see? That thing is gone. How many of you faced this scenario before? Okay. So the way that you do this, maybe you go and change your code, or maybe you go and inject a set time out, like don't know how many seconds, in order for you to do the action quickly and then come back to the flow. So the thing is, this feature in DevTools that exists for probably five or six years already, but no one discovered that. But recently, we do something good. We make it slightly visible. So now if you go to the Elements panel, Styles tab, if you go to this hour button here, if you click on it, there is this function called Emulate the focus page. If you tap on that, now you can inspect it. And this checkbox itself, it is a global setting. You can just turn it on and never turn it off. Okay.

Is it useful? If it's useful, give me a clap. Yeah? Okay. Now you might say that this name, why is it called emulate a focus page? By reading the name, I also do not know this is for debugging disappearing element. This is a good question. No one asked here, but I answer myself, because I get this question a lot. So if you want to understand why this pop-up disappear, there's a reason behind it.

So this sort of pop-up and the dismissible thing, sometimes it's because they are depending on the document that has focus state. So by the way, I'm using this little button here. This is called live expression, which you don't need to refresh DevTools and add in your value from time to time. It will just automatically run every time and keep track to update it. So this document has focus now because I'm in DevTools, means that my document, the page itself, is not focused. So that's why, if I move my cursor to the page, now the document has focus is true.

So if I click on DevTools again, it is gone. That's why the thing is dismissed because the page is no longer focused. This emulates a focus page, basically it's to fit the focus back to the page so that whatever element that you debug based on this focus state, then you can debug it. And we have a long discussion about this feature because this is so intuitive and it's like a regular problem that developer hits. Initially, we want to try making this checkbox enabled by default so that you don't need to think about it and you can just debug your issues. But the thing is, for those of you, if you have some background process that depends on this API, it's called the Page Visibility API. For example, if you open a new page, your document is no longer visible. Turn on this setting will impact this because the page will keep on remaining visible even if you move to another page. So let's say, if you have some, your page depends on some, if the page goes to the background, you have some process to run to test it, then this wouldn't work if you opened DevTools. So after evaluating the risk, we decide to, no, we are not going to turn it on by default, but you can turn it on one time and then forget about it to debug these issues.

So just now I mentioned this feature actually exists for ten years. It is in the rendering tab. Anyone use the rendering tab before? Okay, compared to the hands-up just now, it's much lesser. So this is quite a long process. So you need to click on this three-dot menu. What happened to my mouse today? Never mind, I have a ... Yeah, to the rendering tab. And then you need to scroll down all the way, somewhere maybe, oh, you see, I can't even find it.

Somewhere here. Yeah. So somewhere here, yeah, here. Emulate a focused page. Then you can turn it on to do that. That already exists for many years. The thing is, it is so far away, so by moving it closer, we hope that it solves your, what we do is that we also track the usage. So we saw that 1,500 percentage increase on the usage. So I hope that you are in this 1,500 now and have less suffering when you try to debug the disappearing element.

Okay. Sometimes it takes more than just moving stuff to remove the frictions from your development flow, debugging flow. Take another example, overriding network responses. This feature is also assessed in DevTools for many years. So let me show you what I mean. So anyone of you heard about this feature? Okay. Quite a lot of hands, but also quite less a lot of hands. Okay. So if I refresh this page, what I can do is, for the JavaScript, CSS, and document file, or whatever file, what I can do is I actually can overwrite this style.css file to inject my new style. So for example, I open it in the styles tab. So what I can do is I can go to this area here, click on overwrite, and then enable this local override to try to mock the responses, basically. So if I enable this, what I can do now is that I can start writing some script here. Let's say the background, I change it to lavender. So I can do this, when I save it, it will sustain a cross-page load. It's different from what you do in the elements panel, it doesn't sustain a cross-page load. But this is good, that you can do this, but the thing is, how many steps do you need to do? You need to first see the result in the network panel, go to the sources, find the resource, and not only that, you need to click on this dot, and then to find the override button to enable it first to begin with. So this is a lot of stuff. So what we do now is that in the network panel, what you can do is you can just right-click on a file, and then there is consistently this overwrite header, overwrite content button that you can click. You can do this for the JavaScript file as well, so you can just overwrite the content, and then we'll just save it for you. Even if you haven't done that yet. And moving it closer is not enough.

We also make it consistent that, let's say in order for you to do overwrite, you need to set up a folder locally so that we can store the result in that folder. So even if you haven't set up the folder yet, we consistently show the menu there. So if you haven't set up, we will just show you a setup menu to have you click a folder, select it, and set it up. And if you already overwrite the content, you can come back to here and edit the same file again and again. And we also add a little bit more features into Dit to support mocking APIs and mocking response header.

For example, in this, in here, I like Bobati, so let's search for Bobati. Uh-oh, see? The API endpoint doesn't work. So what do we do now? We probably go to this fetch result and see that, oh, the result is 404. Since this is my local development, I'm developing this website, then I was like, oh yeah, the backend engineers haven't had the result ready yet. So sort of like either we create our own API, mock the API with whatever server, fixed server that you have, or you just change the result in your code. That's another way to do that. What you can do is you can right-click, and then you click overwrite content, and then what you do is you paste in, okay, yeah, I have a data store here, so I will just copy the data, go to the request that I overwrite, paste that in to mock it, and then now I tried it again. The result is here. So I can use this mock result as long as, until the backend engineers say that, hey, the API is ready, then I remove, I delete this overwrite result and use the one that the server provides.

Is this nice? Okay. So, by moving it closer, making the experience consistent, we saw about 200% increment in the usage of this feature. I hope you go and try so that the next time I do the checking again, it will be 400%. And bonus, in order to make it more helpful, there is one more friction that we can remove from this whole process. So for example, let's say now you have finished the development, you deployed it to the production. Very good. When you go to the production page, I do the same thing again. This time, the error is different. It says the type is, like, failed to fetch. So what do I do now? I go and read my console. It says that there's no access control origin. As an experienced developer, I know what this means. But it can be a lot of reasons that are causing this. But as a junior developer, it can be really, I don't know where to start and how can I get more help on this. So the next thing you do, probably you copy this, put this in a browser engine, or put that in any AI tools to ask, hey, what is this error about? The good thing is, there's new features that you have in DevTools. Do you spot the light bulb icon here? You can actually click on this, let's try, and then say that continue.

So it will try to help you understand this error. So it will give you some explanation on what the error might be because. And then sometimes it will give you, like, some code example as well. So if you think that, oh, this explanation is not good enough, you can try to remove it and then try to regenerate it again. So it will try to generate a different result to help you explain the same questions. So let's see. Yeah. So this time, it also helped me to, it also tell me how can I fix the issue. So if I say that, oh, probably I should add this SS origin, this one, in the server. So I know that I copy this and then I tell the server engineer, the backend engineer, to add this to the backend. But sometimes it takes time. So what I can do is I can copy this code, go to the network panel, right click on the result, say that I overwrite the header, and then I can overwrite the response header by pasting it. And then if I do that again, I can go to here. So I can do this until the backend return the result. So you can overwrite the server header.

Good! I did not ask for the clap this time. Thank you! So this is to help you understand better the code. One note, though, these features, we launched this feature already in the U.S. and outside of E.U. We are still, because this is something to do with AI and Gemini. So it's coming soon to the U.U. We'll announce it once it's ready. So if you don't see the light bulb yet, probably you need to wait a little bit until we sort it out. Cool. Next thing, too many data, too many alerts and warnings here and there. It's a noise as well. And this actually distracts you from your actual work. This is also one of the frictions that you might have. So one of the things we do is we also remove some warnings from the console so that you can search for the error that you want and to try to get into that. So if you have seen this error message before, this is a lot.

Especially for those of you who have a lot of Chrome extensions installed, you may see this message. It's good, but not useful because you can't ask the extension to not load its source map, which pollutes your trace. However, in the latest Chrome release, we have removed all these warnings. Give it a try! We also help you debug quicker by ignoring certain things. For example, we ignore content scripts injected by Chrome extensions and some framework code. We also ignore certain files in the node modules. This setting can be turned on in the DevTools settings. By ignoring these folders and files, you can step into your own code instead of the browser code, making debugging faster. It also improves the console messages by removing irrelevant stack trace lines, allowing you to focus on the relevant ones.

We also ignore some of the frameworks folder, some of the framework code when you do that. And lastly, we also ignore something in the node modules.

Now your question is, like, what do you mean by ignore? So this is where DevTools turns this setting on by default in the settings, ignore this. So this is exactly what we turn it off.

So for example, if you are in a Next.js application. Now let me go to here. In the Next.js application, if you go to the sources, you can see that all these folders are grayed out by default because these are ignored by default.

So now your question is, like, how can this help me to debug better? So for example, for some of you, if you set an event listener breakpoint, you want to capture all the mouse clicks on the page and debug that, you can go to this event listener, click on the click event, and when you try to start debugging, you straightaway jump to this function here. And if you go closer, actually, you can have this show ignore listed frame to see, like, what have DevTools been ignoring.

So by default, when you click on this mouse click, because there is React code that's running behind, supposedly you should be jumping to this React code first before going to this active list. And when you debug step by step, sometimes it will suddenly jump to the framework code instead of your own code. But that's not what you want. So by ignoring the node modules folder and this framework file by default, you don't need to worry about that. You can just step by step, step into your own code instead of the browser code. So that makes things faster.

Another thing that it improves is that in the console message. So let's say now if you click on this activate a list button, it actually has an error here. So let's see. If you look at this error message, which line of the stack trace is the one that is related to your code? It's only the first line, right? Yeah. And all the other lines, basically, it's not that helpful for you. Supposedly, if you remove them all, it can be helpful for you to view all the other messages. So with that, we can actually shorten the console error and make fewer debugging costs when you do the testing.

This is the error message that we see just now. It's not just the error message. If some of you do the debugging before, there's a dropdown that you can click on that. There are actually two parts of the stack trace that you can look into, depending on what you are debugging. So on the top is the error stack trace. At the bottom is the message stack trace. So on the top basically tells you where did the error happen. So in this case, the index is on line number 10.

And then the bottom stack trace is to tell you where was the error log, the message log. Because you catch the message in a different area of your code, so the message log could be somewhere different from where the error happened. So the good thing is that in DevTools, we already used that information to collapse the bottom stack trace for you, the message stack trace for you. Now if you click on it, if you expand it, you don't see 18 others framed that is not related to you because we collapsed it by default. You can just click and expand that to look into it.

And the next thing, which is coming soon, is we will collapse this. The final result that we want to achieve is something like this. So this is one line, and then you can click show acknowledge to expand it. Is this good? Okay. This is still a working process, and actually the contribution of this thing is thanks to the Wassell team. They actually sent a CL for us to fix this. So hopefully it will land soon. So the concept here is that, does this thing spark joy? If it's not, then we'll just hide it right away.

And lastly, speaking about hiding, we also have some little improvement here. Last time in the waterfall column, you will see it take the whole space in the network track that now you can actually hide it. And the other one is that if you have a lot of extension and you try to debug your own network result, it will be polluting. Supposedly you can use the incognito mode to do the debugging so that you don't have the extension, but now we added these features to let you to hide the extension URL from the network log itself. So this is quite helpful for you. The thing is, these two features have been someone is creating for a long time. Let me show you the thing. So this waterfall, to remove the waterfall in the stack overflow, it has been requested for six years ago and built 9000 times. And then this one, this year, one of the users, so we also have a bug that created for six years ago. Then we received this message recently. There's too long of the message but the gist is that it used 8000 developers to find the network for nothing but to be a waste of space. So this person has been consistently telling us, hey, please remove it. It's not helpful for us, for six years. So good for you. If you are in the crowd, you finally can do that. And to be honest, 8000 developers is important, but we also received a lot of other requests. For example, the high extension, it's built 24k times, it's created 11 years ago, and we only recently put in the features because you actually have the alternative way to do it, and it doesn't, because there's a lot of activities and we have a lot of features and we have limited resource, so it just doesn't rise up to the priority sometimes.

So be patient with us. If you really want the features, keep asking. If you ask and do not get it, keep asking and creating a feature request to us. And if you want, you can contribute a fix. It's actually a web application, the whole Chrome DevTools. So if you know how to develop a web application, you actually can contribute to DevTools. This is the link for it if you are interested. So what we have done so far this year is that we try to make things obvious, attractive, and make it easy and satisfying for you to use. So I actually also highly recommend this book, so I read this atomic habits books to improve my personal habit, but actually if I think of it, it's actually applied to product, like the UX design as well, on how to help developers, how to help ourselves to do things more easily. So almost there, if you want to learn more about new features and do deep dive in DevTools, I try not to dismiss the what's new tab that pops up from time to time. Click on the link, you will see like some articles and the video to talk about like some new stuff and how can you use them to fix some of the issues.

Okay, thank you. That's all.

Somebody asked how can they find out about new improvements in the DevTools. As Jesselyn said, don't dismiss the what's new tab.

Quick question from somebody but important to me as I work on a Chromium browser that's not from Google. Are these improvements available to all Chromium browsers or only Google Chrome? Okay. So like for all the things I mentioned just now, it's available in all the Chromium browsers. That's great. So that's Microsoft Edge. So one of it is the exception is the console insights, like the button that you click to help you describe, that is not available in the other Chromium browsers, only Chrome. Yeah. Thanks, Jesselyn.

Some quick fire questions. Can I share my overrides with colleagues? Okay, so this is a good question. So if you want to share the override with your colleague, it is possible because you need to set up a folder in your local PC. So what you can do is you can have a GitHub repo for that repo for the file that you created, then you can just commit the code as you do, then you can share it with your colleague. But there is no sync features in DevTools that you can sync the override to the other PC because that would be too dangerous. You sort of need to set up a Git repo or place for you to share that. Thank you.

Somebody asked, Jesselyn, how long does the override live? How long does this? Okay, so this lives as long as it can because it's in your local drive. So what you can do is you can delete that, then it will no longer do the override. Or you just need to check on the checkbox that disable the override, then we won't use your override file, even if that file exists. Thank you.

Alexander asked, how do you differentiate between real styles and data that you've overwritten? Maybe you forget in two weeks that you've got an override on? Yes, this is actually a really good question. So in the network panel, if you see on the top, sometimes it comes out with this triangle exclamation mark, it's a warning icon to tell you that, hey, some of your network result actually changed. We show that warning icon wherever you have stuff that you override or wherever you have changed your network speed, like you drop it to 3G or 4G, you do that. And then in each of the overwritten resource in the network panel, you can see a purple dot that will indicate that these are the requests that get overwritten. Thank you.

And I'm sorry this is a machine gun of questions to you. What is the easiest way to override GraphQL requests? Because all of them have the same URL."

So I get that request, file a request in the Chrome DevTools, just file an issue feature request, because there's no easy way now. Because I know that the GraphQL request is like a big chunk. So sorry, but you can file a request and remember asking and keep asking. Thank you.

The last one, again, back to what you were saying about friction. Somebody asks, Jesselyn, in addition to crbug.com requests and community feedback, how else do you find out about these frictions in Chrome DevTools? How can we let you know? Okay. So one thing, of course, is crbug.com is our main resource. The other one is Stack Overflow. So in Stack Overflow, you can file your questions under Google, I think Google Chrome DevTools has a Chrome DevTools tag. And then, from time to time, I will look into it. And then to answer questions as well. And to understand, are these requests highly viewed? And then is this something that we can do immediately? And also social media. So if you tag Chrome DevTools in the X platform or you tag me, I will also look into this request and log the request, the feature. So these are the social media, crbug, Stack Overflow, YouTube, the video under it, I left the comment. We'll use all those. Yeah. Thank you.

Okay. I want you to give a huge round of applause to Jesselyn Yin. Thank you.