 Hello, everybody, we thought we'd do a supercharged reunited. I think that's what we're going to kind of have to call it. It's not quite live, but it's almost live. It's almost live. Yeah, we figured that home internet connections, things could go a bit weird. We rather you're actually entertained and interested in what we actually tried to cover in this session. So we thought, well, we'll just get it down. We're going to be actually live in the chat as this is we're going to do this as a YouTube premiere. So do chat away. We will be in there. We'll discuss things with you as we come out of the video. Future selves, or I guess it will be present selves at the time, watching our past selves, but chatting with your current selves. Why are you making this complicated? Why are you making it so complicated? Right, so let's talk about what we're going to do today. So I'm going to act as kind of the eyes and the watching on as you attempt, for the first time, to make a change in Chrome DevTools. So if you've never come across Chrome DevTools, it's a tool that a lot of people use. What are you doing here if you've never used Chrome DevTools? And yet at the same time, I don't want to assume. So if you haven't, and you're brand new to, that's what it is, it's the developer toolings in Chrome. And this is Serma's first attempt to actually patch something in to Chrome DevTools. So we have a bug that we identified earlier as a good candidate. And to be clear, so you've never done this before, right? So you've never made a change to that. No, so I just recently did my very first commit to Chrome, which also was a very, very tiny change, but it was so tiny that I could focus on all the other scaffolding around it. And that was very exciting. And I think it's only been a recent change that DevTools is now its own little repository, its own project, which actually makes it way easier to contribute to. And I think that's actually what you've been working on for a couple of months now, the whole breaking out DevTools, its own thing, making it more approachable for developers. And so now you actually get to show me the fruits of your work. So, yeah, you're right. The DevTools repo is actually a separate repo to the Chromium one. It's part of the Chromium kind of umbrella, yeah. It's a part that it's still a Chromium project, but yes, it has its own separate repo. So it gets rolled into Chromium every so often, every few hours, I think it is. And that's how we develop it. So it has its own pipeline for getting changes in, which is very similar to changes in Chromium. But anyway, we'll get to that. Now, you can actually see actually on your screen, if I'm seeing this correctly, this is the repo that you clone. This is not an internal URL. This is out in the public for everyone. Everyone can clone this, everyone can work on this. And that's kind of what we wanted to show today, that apparently, if I can contribute to DevTools, so can you. I mean, technically, this is your second commit, because you can see actually- I mean, basically, that's a cheeky commit. We just want to make sure that it works before we go out with big fanfare and then it doesn't work. So I made very important changes to a file called white spaces where I added my name. All right, so if you were going to do this for yourself, and this is something that you've already done already, you've been through this, read me to go and grab the source code. So if you scroll down a little bit- So that's the workflow section. Yeah, which if you're going to build Chromium, you can absolutely do this. We won't be building Chromium today because it takes a long time to build. And it's not actually strictly necessary for the changes that we're going to make today. So again, I guess we'll get into that in a little bit. So one thing you will have to do is say the depot tools, which is like a little wrapper around Git and some other stuff to give you the commands that the Chromium team uses to work on both Chromium and on DevTools. It's literally just like a folder that you put somewhere and that's it. It's not very complicated. And then- You clone it and add it to your path, basically. Yeah, pretty much. And then you follow this, read me. It's very well explained. And it worked first try for me and I didn't do anything special. And so in the end, once you do this commands, you suddenly have all the source code for DevTools on your local hard disk, just like I have in this terminal. There we are. Okay, so you're starting from exactly that checkout point. So the first thing that it's probably worth doing is just checking that we can actually run your own build of or your own instance of the frontend, the DevTools frontend from a copy of Chromium. So what we do is when you run, there's a command called GClientSync, which is part of the DevTools. So if you run GClientSync, this gets any dependencies of DevTools. And one of those is a pinned version of Chromium. So you probably didn't see it there, but one of the hooks was download Chrome Mac. It takes longer on the first time because I already ran GClientSync yesterday and saw the binaries already there. Now, if you look inside, say, the third party folder, you should see third party. There's Chrome in there. Yes, there is. And then you'll be able to run Chromium Mac, and then it's Chromium.art. Oh, so that's just like as if it was installed in my applications. Yeah, yeah. So I can do Chromium content, Mac OS. Chromium. There we go. And if you run that, boom, fresh Chrome. So if you go to Chrome colon version, yeah, you're gonna see this is the build, the revision and the Chromium 83. So this is a recent build of Chromium. So if you were to open DevTools in this, you'd actually see the bundled version of Chromium that came with that particular build. And what we wanna do is we want to re-root the DevTools so that it loads from your local file system. And we can do that. So if you quit out of this version of Chromium. Let's close this version. I'm gonna go back to the top level folder and okay, continue. So yeah, so you do dot slash third party, Chrome, Chromium Mac and just get yourself all the way back to that binary. Yes. Okay, now we add a flag and the flag is dash dash custom dash DevTools dash frontend. DevTools frontend. I'm gonna go full screen so we can see the entire. Yeah, and then equals. And then you have to include the file protocol. So it's file colon slash slash. Okay. And then now you do the absolute path to your folder. So whatever it is, it's like slash slash slash slash. Oh, so it would be like user's surma source. You can see my path here. I'm gonna do a little trick then and just go, my current directory. Yeah, and then it'll be front underscore end. All right. And I don't know if you need the training. I don't know if you need the training slash we'll find out. Now we're not gonna notice any difference if we get this right. No, it's just DevTools, isn't it? Yeah. So the thing to do, if you go to the code, so if you boot up the source code, like your VS code or whatever. Close this, I have VS code open here. Yeah. If you just do a search for elements panel.js. So this is the JavaScript that backs the elements panel. And I should have said the DevTools frontend is just a web app. I say just a web app. It's a web app. It's a web app. It's a complex one, but it's a web app. It's a very, very large, long running web app that's had loads of time to mature and so on. But nonetheless, it is a web app. And so if you're comfortable with JavaScript, you could theoretically work on. You could. It might still be a bit overwhelming because I'm certainly overwhelmed right now. Yeah. So after that super call for the elements panel, let's just like console.log something. I'm just like. Why after the super call poll? I could do it before. I thought you had to do a super call was the first thing. No, we can only think you can do super later. You just cannot access this before the super call. So let's put a console.log debugging is still state of the art. So now have you got the Chromium build open that you had? Oh, no, I closed it. I thought. So you didn't actually have to. So you don't have to do that. We don't have to build or anything? Don't we have to like build? No, in this particular mode, we don't because we just reroute all requests through here. Oh, that is neat. So now you've got DevTools. Now, if it's docked to the right, you can't do this. But when it's undocked, like you currently have it, you can inspect DevTools with DevTools. So you hit Command, Command. Yeah, yeah, exactly. Inspect. All right, so let's do this slowly. This is probably a tricky part. Go away. I often open DevTools with Command, Alt, I. It's just open DevTools. But since DevTools itself is a Chrome window and just a web app, we can inspect DevTools itself with the same command. Now, we have two DevTools, and you can see these are the logs from that DevTools. Yes, exactly. So the DevTools on the right is the one that's inspecting the page, and the DevTools on the left is inspecting the DevTools on the right. Now, that might cause your head to kind of go weird. It's insane, isn't it? Yeah, but if you click on the Elements panel on the right-hand one now, on the right-hand one. Yep, yep. Hey, we changed the thing. We changed the thing. Can we ship this to Prod? Because I think this is a really good change. No. Although, so to be clear, actually, we're going to fix a bug today. And the bug, I am going to approve the fix on my side, because I'll be watching some, and I'm comfortable that we're going to get to a good solution. So I'll be able to improve it. You should regret that statement. Yes, let's see how we get on, actually. Let's not commit to too much too soon. Should we look at the bug? Yeah, so the bug is the ID. CRbug.com. I don't know. Let me find it. Yeah. I thought you knew it. Unbelievable. I remember, we looked at it earlier, but I forgot ever since. OK, so the bug ID is CRbug.com slash. Just waiting for it to load. Is 1, 0, 2, 4, 7, 2, 1. Now, this particular bug is an interesting one, because it's saying that the payload size in our showmore tooltips is double the correct value. So let's go to the dev tools and in the console, let's do something where we would force the show more. So this would happen if we had an object or a string. Actually, a string would do it by itself. That is too long for us to just show in the console. What we do is we truncate it, and we add a showmore button. So like, yeah. OK, so we make it really long. So let's make it like 1 megabyte long. Yes? Yeah, try it. Ah, that's the thing. It says 2 megabyte. Yeah, so what you did, if you just bring that command back that you just had. By the looks of this, you created essentially 1 megabyte of data, and our showmore. I would have assumed so. Yeah, is showing 2 megs. So that's the bug. The question is, first of all, is that a valid bug? Is that actually a bug? Is it a bug? My understanding was that the JavaScript characters would be 2 megabytes long. Oh, this is about string encodings, isn't it? I think so. So I mean, in normal land, I almost said, like if you use ASCII encoding or UTF-8 encoding, these characters are all 1 byte. Right, so if you do dot length, that's just going to say 1. So why is that not just 1 byte? Or is that 1 byte? That's 1 byte, right? So I think JavaScript is standardized to use UTF-16 under the hood, which means that the underlying byte representation of the string is 1 character long, but the byte length is actually 2, because each character has 2 bytes. OK, well, in order to figure out what's going on, we need to go and find where this is happening in the source code, just figure out what it's actually doing, and then we can actually see whether it's doing the right thing. How do they go about that? Yeah, this is always the most interesting part, is to kind of go, OK, what is this thing that I'm even looking at? So you've got DevTools with DevTools. We'll actually start there. If you use the arrow in the, you know the? This one. Yeah, that one. Yeah, the arrow in the box. That's like. By the way, I love using command. So as it says here in the hover, command shift C is the shortcut. So you can just click here, go command shift C, and then. Yeah, so if you highlight the show more 2.1 meg. Oh, I need to do it here. Can I get to the show more button? I don't know. Let's just click on that one for now. I think I broke it. Oh, yes, there it is. OK, boom. We have found a button. Let me make a bit more room. OK. Yeah, so there's nothing in that particular class that makes me think, oh, yeah, I know exactly which part of the DevTools. But we could look at eventlessness, right? Which object property section.js. Yeah, so that would be where I would have assumed we were going to get end up. So I guess if you switch across the VS code, go find that objectPropertySection.js, and then we can talk about what that is. Let's go there. ObjectPropertySection.js. So yeah, I mean, in the same ways you do normal, I guess, forensics work to try and figure out if you're looking at any other web app, like what part of the code is this? Yeah, exactly the same kind of deal here, really. This app is quite big. So I basically assume you go and blind every now and then just have to do the usual detective work. Yeah, I mean, like anything, once you get used to looking around a certain code base, you kind of get ascended where things probably are going to live. But I know, so the objectPropertySection.js is the DevTools.js way of when we get given an object to render to the DevTools.js UI, the objectPropertySection.js is the thing that does that for us. It creates a tree because you're going to expand and collapse the properties and so on. And then within that, there are the various types. So we might be showing a number or an array or even another object because they could be nested, or we could be showing strings. So there'll be one that's actually dedicated to showing strings. So I guess we just, if you want and hit Command-K zero for a second. Yeah, right, Command-K zero. You have to hold Command-K. Command-K and then there you go. That will collapse everything. So if we have a... Oh, handy. Yeah, so that's one handy thing from VS Code that I love. If you get a big file with lots of stuff in it, and for us DevTools files are often quite large. Look how short it is now. I can scroll through it in like two screens. The other thing that's really useful is going back. When you're kind of control clicking or command clicking around a place, then you're like, I got lost. I need to go back to where I was before. Command-minus, right? Yeah, Control-minus I think is what it does. So, okay, so I see the one at the bottom there. Line 1634, expandable text property value. Because that's what it is. Because it is because it's our expandable text property value. Yeah, it's a good name. It's very descriptive. Okay, it should be unfold this a bit. Yeah, unfold this one. And let's go on and see if we can figure out... Can I unfold all of this somehow? Or is there also shortcut for that? It's K1, I think. Command-K1. Okay, so I'm gonna... Ha, ha, ha. Okay, go here, Command-K1. Maybe not. Maybe not. All right, I'm just gonna do manually. Why not? We don't care about comments, who needs comments. Who needs comments? Right, I can see it already, dude. Oh, this, ah. Okay, okay. So there's definitely something to explain here. Firstly, number dot bytes to string. So you might be looking at this if you're familiar with your JavaScript. You might be thinking, I don't remember there being a bytes to string. We have some utility functions that are currently hooked off prototypes in the DevTools code base. We're actually working to remove those right now. So move them to... I was gonna say, because that's not a best practice, is it? Right, it's not a best practice. Messing with the prototypes. Yeah, exactly. So that's why we're trying to move those to make those self-contained functions so you can have like a bytes to string. That takes a number and then returns you back. It doesn't need to live on the number. So I guess that does the whole thing where it also adds a suffix for the units? Does it do that? Or is it just like turning... Yeah, it does it. If you actually look at the implementation in FATS, if you just... I can't try to remember where it is. F12, right? Try it. I mean, yeah, because it can't find it because it doesn't know where it's... Oh, it's a different number, of course. But if you... Like, command shift F and look for bytes to string. Bites to string. Yeah. Let's go down, keep going, keep going. Are we looking for something like... Timeline UI? No, keep going, keep going. It's not in there. I'm at the bottom already, and it's... Okay. I must have missed it somewhere. I would assume it'd be like a number.js or something, but that doesn't seem to be the case. No, don't do the open parent on the end of your search. Sorry, I didn't notice that. Oh, it could be an equal thing, of course. No, I just assumed there would be a parenthesis, but it doesn't have to be. I think it should be in common. Is this alphabetically no? Okay. This is fun. Trying to go find it. I'm gonna see if I can find it for myself on my side. I think I might have to increase the space here a little bit to see a bit more. Ah, bytes to string equals functions. That sounds... Oh, that's wasm parser. It's in common. It's in common. Oh, no, it's not. No, it's not. Oh, man. So there is one in wasm parser, but I'm guessing that's the one we're looking for. It is not. Ah, UI utils. UI utils. Yeah, I'm just literally about to say that to you. Okay, we can see the implementation of what that's actually doing, which is kind of cool. So, yeah, the number of bytes is less than 1,000. That's how we do it. So this common UI-UI string, again, is like a formatter that we have internally. So we have lots of helpers to do lots of different things. I see. Okay, fairly straightforward. You can see, if you've done any string formatting in the past, you'd recognize this kind of formatting style, I think, with non-breaking space and bytes, and then the right suffix. Anyway, the point here, though, is that line one, six, five, one. There's one. Take the text length and multiply it by two, right? Now, I'm wondering, it is definitely unexpected, but is it wrong? Because... Well, yeah, it must be wrong, because like, when you did that example before, the exclamation mark was one byte, right? So it can't be... So that can't be right to how... No, no, it was length one. It was a string of length one, it has one character. That doesn't necessarily mean how many bytes it consumes, because you can encode the same string in many, many different ways. So that's, you know... True, so what's the assumption that... Is this is assuming two bytes per character? Pretty much, pretty much. And that is... That's not always gonna be the case, right? I mean, most things... Right, I want help. I want help, really. Because... Shall we summon the only person who comes to mind, for me, when there is questions about JavaScript, standards, and text encoding? Who are you thinking? The Binance, the Matthias. Oh, yeah, Matthias, Matthias, Matthias. Let me see if he is free. Okay, can you join? We need your help. I'm gonna put our Hangouts call on the main screen now, so because if the Matthias joins us... He says he can, which is good. Yes! Wood! Oh, hey! How you doing? Right, how's it going? What's happening? We're doing a video, and we are discussing a bug where DevTools currently reports a number for the length of a string that looks like twice the number of characters. And we were discussing bytes, and I'm confused. And we suggested, well, Serma suggested that you were the right person to bring in and ask. So, can you show your screen, just so we can show Matthias what we're actually looking at? Yes, I can. Thank you, by the way. Share my entire screen. Ladies and gentlemen, it's Matthias Binance. If you don't know Matthias, he works with me on DevTools, former DevRel. Here we go, so this is the line that Serma is now isolating for you. Okay, can you show him your... Which line is it again? Yeah, could you show him the console though, just for a split second? The console log, that is this one. All right, so what I did here is, ah, sorry, so what I did here is I created a string that has one million exclamation marks, which my intuition was like, that is exactly one megabytes of text. DevTools, however, tells us 2.1 megabytes, and that is a bug that has been reported. And now that we've dug down to where, how this is being calculated, it is definitely unexpected, but is it wrong? Yeah, so that's my question. So like if you go back to that one line of JavaScript, total bytes is, we were just talking about bytes to string is just, I mean, that's a nice little side thing about the fact that we take the number, but the fact that we got two times text of length seems to me to assume two bytes per character and that seems wrong. Well, I guess it all depends on what the intention of this code is at the time it was written. So clearly the number of bytes that you get for a certain string depends on the kind of encoding that you're using to encode that string in the first place. Like the same string, the same inputs could produce, I don't know, 34 bytes in UTF-8 and then another number of bytes in UTF-16 or in UTF-32 or in any other encoding you come up with. So this code looks a little funny at first, but I think this might be correct for UTF-16. Right, and that's what JavaScript uses, right? Or JavaScript is standardized to expose string to the developers in UTF-16. Yes, yes, unfortunately, this is, I mean, there's lots of background here that we probably shouldn't get into right now, but people might have seen this thing before where you take, it happens a lot with emoji, a lot of emoji have this property where you add them to a string and then you get the length of that string and the length will be two instead of one. Let's show that because that's something, that's one of my favorite things. So if we take a string. What we're gonna need to see your screen again, buddy? Yes, hang on, I'm recording that, but you can see it. So that's funny, I'll do that again. Give me a second, so I'm gonna share my screen again, this one, and I'm gonna do this again and type this one. All right, so because what you can do, if you wanna have a string that has, for example, the poop emoji, that is all perfectly fine. However, make it bigger, make it bigger, we wanna have this in really big, there we go, nice and visual. However, if you take that string and you look at the length, it says two, which means it has two characters, which it does not. It's clearly just one poop emoji. But it could be two characters, but four bytes or eight bytes or presumably depending on the encoding of what you've actually got here. Well, so that's, I guess, yeah, Matthias. Right, so the JavaScript string length is not directly related to any kind of encoding or at least it doesn't directly correspond to the number of bytes in any particular encoding. Oh, okay. And that's why you have this little formula here, like you take the string length, you double it, which happens to match what happens for UTF-16. Because for UTF-16, there's this concept of a code unit, which is like the word size a certain encoding uses, the smallest logical unit that makes up the part of the encoding. And so for UTF-16, every unicode character, well, let's say it like this. A lot of unicode characters, they correspond to one code unit in UTF-16. They can be encoded in one code unit and each code unit is 16 bits. Everything up to 16 bits, right? So the first 65,000 characters in unicode should just easily fit into two bytes. But there's lots of other unicode characters, over a million actually, that do not fit in just one 16-bit code unit. And the problem there is that you need to represent them somehow. So the way this works in UTF-16 is that instead of using one code unit, you use two. And then during the coding, you combine those back together. Okay. These are surrogate pairs. I cannot be the only one for whom this is unintuitive and a little bit bonkers. So I'm glad, first of all, I'm glad CERMA understands and I'm glad you understand. I'm gonna represent everybody else who's going, I understood some of the words that you used broadly, maybe. Is there a blog post? I've a feeling you have a blog post that at least covers some of this. There is a, I can send you a blog post here. Okay. In which case? It covers all of this. I will check that in the show notes. For now, my understanding is that UTF-8 is the component, like whenever you do node work, like when you're reading from a file or whatever, it's always UTF-8. So it feels like this is defaulting to UTF-16, whereas UTF-8 would be nearer what a developer would most likely be encoding in. And therefore it's much more, it may not be perfect, because if they are working in UTF-16, this would be now, would be wrong, but a more mainstream encoding would be to use UTF-8. So we need to find a way of calculating the bytes, assuming at least we're probably going towards a UTF-8 encoding and see what that actually gets us. Is that a fair? Okay. I think that makes a lot of sense. Although, I mean, currently it's apparently using UTF-16 and I don't know what the reason was for that. If I had to guess, it's because DOM strings, like every string in the DOM, and like Surma said, JavaScript strings, they kind of use UTF-16 to some degree. I like that. Maybe just go trender. It's complicated. You don't want to know. Okay. But since you know perhaps a little bit more about this than we do, if we were to ship this, instead of going two times the text length, if we were to ask for its byte length based on a UTF-8 encoding, and that would seem like a more reasonable approximation. In general, I think UTF-8 is a more sensible default than UTF-16. Especially for something like DevTools, where you might be inspecting a network request, where, I mean, it's definitely a best practice to use UTF-8 to serve your HTML, CSS, JavaScript resources. So it would be weird to send it in UTF-8 and then look in DevTools, and then suddenly you see a byte size in UTF-16. It's also, without being mentioned. We have the copy button. So if you copied that string in your editor and save it as a file, there's like a 99% chance it will save it as UTF-8. So I think UTF-8 is pretty much the predominant encoding on most platforms. And so I think it's, nobody would argue with us defaulting to UTF-8. All right, in which case, that is, I think, our path forward. Thank you, Matthias. I mean, you're welcome to stick around or you're welcome to leave, whichever you like. And if you send me that blog post, I'll chuck it in the show notes. Yes, we'll do. Again, thank you, my friend. Yeah, thanks for having me. See you later. See ya. See ya. Right, okay, so we have, whoa, such a simple bug. And now it's gone into text encoding. And I'm glad we got there. Okay. Yes. All right, back to the code we go. Let me undo all my, because you probably don't want to have these empty lines in your CL later on. No, we're not LGTM, no one. So in case anybody's wondering, LGTM is a short handle we use, which means looks good to me. And it's the, the LGTM is like a plus one. It's a, it's your good to go. And so when I say I wouldn't LGTM, it means I would not say that it looks good to me. So the plan is to get to an LGTM, which we will do because I'm watching so I'm occur this anyway. Okay, so we can comment this out because we know this doesn't do the right thing. You want to write something new. So usually what I would do is I would do something like new response, text, array buffer. And we have to have to await that because it's asynchronous, which is good and then do byte length. But you can't, you can't because constructors is not async. So you're not like. I know, I know. But I guess even if it was an async function, you wouldn't approve it. Because this is, let's do, let's do the proper way. So the proper way as well. We can do a blob, right? That's one way of doing it. No, because if so new blob would work in a similar way and we had would do new blob like this. However, it's also asynchronous. Is it? So yeah. No. Yes. Promise array buffer. Oh, you don't have to get an array buffer. You just ask for the dot length or the dot size. But then, oh, that's true. Yeah. So I guess what we could do is size. There you go. So that should get us the right. Well, since you've gone that route, let's just try that because you can, so if you go back to the Chrome event, you don't need to restart it here. So this is where you have to get it right. Right. So on the right hand side, which is the one that's the kind of correct one, the one that's actually inspecting the page or like that, not the dev tools on dev tools. Right. If you hit Alt R or Option R on Mac or whatever, that will. Oh, it reloads. Reloads dev tools. And then you can inspect dev tools if you want. But we could just try your. Yeah. So we're just going to do this thing again because we still have it here. No, that's not the one I wanted. I wanted the one, this one. Yes. Ooh. I don't know why I didn't format it correctly. Oh, because you know why I didn't format it? Because I didn't call. Yeah. Let's fix that. But we know that the number is now. It's roughly a megabyte, which is exactly what we want to see here. Okay. So we would just basically do the same thing that they did to number bytes to string. Do another reload. There we go. 1.0 megabytes. Boom. Love it. Okay. It feels weird to me to create a blob. Yeah. Because also blobs might get persisted to this because that's the point of blobs that you can store blobs and files. And so that just seems not like good. Yeah. What you usually do when you do text encoding is to use a data structure called text encoder shock. So what we're going to do is encoder new text encoder right this. And then we can do, we can encode the string. So text encoder only has support for one encoding, which is UTF-8. So I think there used to be plans for more encodings, but just basically it ignores any parameters you give it. It just gives you a UTF-8 encoder. Because that's a nice feature of this would be if we could parameterize the encoding. And then if we knew that somebody was working with UTF-16 to show them the bytes based on whatever the encoding should be. But okay. That would be nice. Let's platform onto UTF-8 because that's pretty much the same on the web as Matias had anyway. So encoder.encode typing is hard. I feel like you've been to my school of typing today. Yeah. So encoder.encode and you give it a string and the string is called, I forgot what it's called now, text. I could have guessed that. So this is now the text, the string in whatever the engine uses internally encoded into a buffer containing the UTF-8 sequence. So do we want buffer.length then presumably? Buffer.bytelength is what I would use. Yeah, because this is a buffer. Oh, it's a U&8 array, which is a view onto a buffer. And the byte length gives you the number of bytes which is what we're looking for. And now we format that for the total of bytes. Okay. Okay, check it out. We're gonna reload DevTools once again and it's still working. Boom. Okay. That is the fix for this then. So if you can delete that line one, six, five, one. Delete the old line. Okay. Delete it. Okay, so let's have a look. You need to close that. So that's what we're now gonna do is we're actually gonna make the patch on the DevTools repo side. You actually have two changes by the look of your VS code which probably means that change that you made to the elements panel is still. Oh, that's still in there, isn't it? Yeah, let's remove that because we definitely don't want to. Yeah, one change to one. That's our diff. Really. Okay, so what we can do now is we make a commit with that in. Okay. So the way to do that, yeah, just do what you feel like doing there. So fix is, What was it called? Elements. I can't remember. No, that's the wrong fun. Expandable text property. You know what? Copy lazy. That's the right thing to do. Look at you. I signed my commits. Of course you do. That's absolutely great. Now what we need to do is we need to upload the code for code review, which is the same. Okay. It's gonna be fine because I've seen you code this today but normally this would be like an independent process where you would have somebody who's not seen the code look at it for the first time. So you've made your commit. So what we need to do is we need to get CL upload. And if you're used to get, you might be thinking, I don't remember there being a get CL. This is exactly the demo tool stuff that we talked about earlier. This is adding a wrapper to get or a load of utilities to get CL. So CL is short for change list. It's very similar to a PR on something like GitHub. And you see here, it's taken the commit message that you have fixed size calculations in expandable text property value. And it's gonna make that the title of the, CL. So what we need to do is we need to pop in the bug number from the... Which we have right here, luckily. So I can just copy paste it in. Yeah. And then we need to add a description in to describe the change that we've made. So I guess explain them. We're going from UTF-16 historically. Oh, okay. The assumption of UTF-16. And this CL is gonna bump us to using UTF-8 or assuming UTF-8. So previously the code calculated the size of the thing when using UTF-16. So you want to go to a new line because that... Yeah, I just saw there is this line here which tells you how long you can go. Okay, so we're gonna line back there. Same thing when using UTF-16 as the encoding. However, oh, that's not how you spell that. UTF-8 is much more common on the web and for web development. So it makes more sense to use that. This CL... You've got to double makes by the way. So it makes more sense to use that. Well, look at you. We'll spot it. This CL changes the size calculations to use UTF-8 instead. Great, perfect. So if we save that... Save it. Yep. So what's gonna happen now is the CL is gonna get created on the upside, on the other side of the remote side. So we can do git CL web and that's gonna open up a link for code review. Oh, that's neat. Yeah, it's really handy. So there we go. There we go. There's a tab. Okay, so in order to make this work, you would need to be signed in, which you're not currently so I guess you need to... You need to switch across to your Chromium account. Yes, so I have a Chromium account. Do you need a Chromium account to contribute to this project or can I also do that? I don't know, I actually don't know. I've never really considered it because I do have a Chromium account just by the nature of my work. So I actually don't know what the process is there. However, we do have plenty of people who make code. Okay. All right, so in this window, I'm locked in with my Chromium account. Otherwise, it pretty much looks the same. I mean, there's a bit more... Let me switch back and forth. There's a bit more buttons going on, I think, because I'm locked in, but other than that, this is the description I just wrote, right? It added a change ID thing to that, cool. Yep. So in terms of running through what we've got yet, so you've got that, that's the file with the diff of what we've changed. So if you scroll back up now, I suppose the interesting parts are the things that are worth discussing briefly. There's the actual ID, the 2134287, it's in the top left-hand corner. It says it's a work in progress. In theory, you can code review plus one. It depends on your permissions whether you can do that or not. There's a thing called CQ dry run, which you can see about two-thirds of the way across. We'll talk about that more in a moment. Rebasing, finding an owner, which is basically, get me somebody who can code review this for me in case you don't know who to ask. Abandon the change and then make some edits. So the thing to do now would be to add me as a reviewer. So if you go to add reviewers, or add reviewer on the left-hand side, it'll pop up a box and you can choose me and the top person there for you. That is you, anyone else? No, it'd be fine for now. Just go with me, start review. Okay, great. So I will now get notified that you want to do code review. Now at this point, you can actually start running the tests, which is probably a good thing to do. So if you hit CQ dry run at the top. So CQ stands for commit queue. And what commit queue does is it takes this change from this change list, which as I say is very much like a PR. And yeah, so it's going to join the back of the queue, essentially. And we have, if you scroll down a little bit, we have a thing called, you can see it says, it says no try jobs, that's about to change. We're about to see, there we go. Literally as you say it. There you go. These are a bunch of machines that are going to step through a load of tasks to do with testing, to do with linting, to do with building and so on. They're just going to run all in different environments with different configurations. And they're going to run through the source code of DevTools with your change applied. And if everything goes green at the end, that means everything has passed all the tests and everything's happy. So you can see it's gray for most of this. It means they are queued up. The yellow ones mean that it's running. Green means it's going to be successful and red would mean that we've had some kind of error. So we obviously want green across the board. Okay, now you're running this. In the background, I can approve the source code change. Yeah, I just showed up here. There's new messages on this change. That's exciting. Yeah. That's the commit bot. Okay. Yeah, but also the fact that it's trying the patch. So it's going to try and do that. So I can step in now. I will get an email that basically says that you want to see. Does this actually look good? Did someone write decent code? Yeah, so I'm going to approve it. Normally we'd go through the process of a proper code review and we would actually sort of discuss things that need to be discussed exactly like you would on, say something like GitHub or whatever. So that's exactly what we do. Process we're going to go through. But today, because of the way we've done this, it's not a problem. So now if you were to refresh this page, which you're perfectly free to do, it doesn't change anything if you see what I mean. You now see the top, yeah, you've got a code review plus one from me. And it also says that you're in the top left that you are ready to submit. So that means at the end of the CQ drive run, we would now be allowed or you would now be allowed to actually commit this code in. Now if there's a problem, we can revert the code later on. So it's not a problem if we actually encounter issues with this later on. It's not ideal, but it's also, you know, resolvable. So we have the first screen tested basically. Well, if you scroll up for me, since we're already here, you can click the submit to CQ button. Despite the tests not being done yet. Yeah, all it does is if you see it on the left hand side, it says commit Q plus one SIRMA. If you change that to submit to CQ, that should now change to being plus two. So what's going to happen now is at the end of the CQ drive run, it's actually now a proper CQ run because the drive run, it would have gone through all the tests that we discussed and then it would stop and it would wait for you to actually hit the submit button. But now what we're going to do is by hitting the submit button, yeah, you can see that it's actually now rerunning those first two pre-submit ones. And the other ones, they're already pending, they're already waiting. So we're just going to wait for those to go yellow and show that they're actually starting to do some work. I mean, we could just leave this and you'll actually get an email at the end of this that tells you the outcome of the run, whether it got submitted or whether there were any issues that prevented it from being submitted. So that's kind of that. If you scroll down for me, the tri-jobs that were there. Okay, so we've got front-end Win64 rail, so that the difference between some of these, if we start on the left-hand side, DevTools front-end Linux, which is the platform, Blinklight rail and Blinkrail, they're fairly, fairly similar. They're going to run tests from Chromium. So there's things called layout tests. And the layout tests are, there's a suite of tests that run in Chromium to check that things are behaving as expected. There are some that relate to DevTools. And so those are the tests that are running on those machines. It seems fairly unlikely that a change in DevTools can break Blink. But I guess there is a situation that it might actually happen. We just want to be on the safe side. So when we talked earlier about how DevTools is now its own repository, it was historically in the same repository as Chromium. So it was more that those tests lived there. Currently, those tests still live there, but we run them, we pull them across and we run them here. I understand. But that's the hint of that, I suppose, in some senses. It's not that you're going to break Blink, it's just that that's where they currently live. They live in the Chromium repo for kind of historic reasons, I suppose. The ones that are still gray, or the two middle ones that are gray, are Frontend Linux rel and Frontend Mac rel and Win64 rel. They are specific to the DevTools repo and they're going to run things like unit tests, link tests. They're going to type check with closure. So we do use JS doc extensively inside the code base to do typing. But there is some use of TypeScript as well inside the code base. So if you actually click on the Frontend Win64 rel, the yellow block, that will actually allow us to see what that bot's currently working on. Oh, cool. So you can scroll down this list. This is the list of all the things that it's currently doing. Most of these don't really... Just set up the environment, don't they? Yeah, exactly. They're doing various things that they would do as part of running, see, right at the top, running recipe and what the recipe is. And you can get the standard out from each of those processes. So if you just refresh for us and scroll down, see what's there. We're still in compilation mode. Eventually, we will see other tasks appear for things like unit testing and end-to-end testing, which are slightly more interesting. I'll tell you what you can actually do while we're waiting for that to get to its point. You can actually run things like the unit tests for yourself, locally on your machine. Now, as we... I don't expect so, yeah. Yeah, but I mean, we're running these on Windows, Linux and Mac, which means we get much more coverage because you're running on Mac right now, yeah. So what you can do is you can do npm run unit test from the root of the repo, yeah. That will compile any tasks using... The same Chrome binary that we've been using for local development. Yes, exactly. Yeah, so it means that we can be certain that we don't have to build Chromium, but we're also not using whatever the device Chrome or Chromium is because there's somebody who might not actually have an instance of Chrome or Chromium on their device if they're developing... Or extensions or any sort of things that could interfere, right? Exactly. So in order to make sure that we get a much more reliable environment, that's what we do here. Now, it's triple, quadruply compiling. It does do this occasionally and I'm not sure I understand why. There we go. It's now booting up and you can see that you're running the tests. Cool. So this is one of the tasks that we would expect the bots to do. So if you switch back... Yeah, let's go back and see where it's at. It is done with compilation. Oh, so it's done with unit test. So if you go to that, to the standard out there... To the standard out, okay. Yeah. That looks familiar. Exactly. And you'll see that in its case, it actually has coverage data. We actually can pull the coverage report if we need to. And we can do that locally too. Tells you which lines are uncovered. That's really cool. So we're increasing test coverage daily. That's something that we're very committed to getting good test coverage on our machines, or on our code, sorry. So yeah, exactly the things that you're in locally. We just run them remotely and some other bits and pieces besides. So now if you go back, it was doing the limp check with ESLint, eventually Linux is now booting. Mac will get there eventually. Yeah. So on the end of that recipe, when it's finished doing all those tasks, hopefully if everything's been fine and green all the way through, then that block, whole block will go green. And as I say, we want them all to go green. So without all said, I guess because of the joy of editing, we'll just jump to the point at which this is all, hopefully is all green. So, see ya. All right, and we are back. That means we are actually done. All these bots you can see now, these tri-jobs have gone green. Ah, and you can see the boss analysis. All of them. And that's actually quite some time. We've been here quite a long period of time. I wanna say half an hour or something? Yeah, it takes a while for these to run through. This is the slowest part of the process, normally to actually get the change in. You know, there's a lot of things that have to happen. Right, now the good news is because everything's gone green and because you'd hit the commit to submit to CQ button, which if you remember was the commit to CQ went to plus two. That was up here. Yeah, it should just be the case now that if you refresh the page, all things being well. Merged. Merged. Top left-hand corner. Merged. Merged. So, you've got your first proper change into DevTools that's landed, which means that eventually that would make its way into Chrome DevTools and hopefully that will also, well, the other thing that you can do now is if you go to the bug itself. This one right here. Yeah, and you'll see at the bottom, that you can see actually there's a, it's not come in yet, is it? Okay, eventually there'll be some data from the CL that comes in here, but you can mark that bug now as fixed if you like. Ooh, I shall. So, the problem is, yeah, you're not signed in there yet, but okay, great. And then you've just got to mark it. All right, let's go to the bottom and I can go from available to- Are you sure? Normally you would have done that as started actually, but we did it very quickly today. We're just so quick. Fixed and then you can save that and that will, there we go. That's exciting. So will this fix be in Canary in like tomorrow's Canary or something? I don't know how quickly it will land in Canary, but it will land fairly soon. And yeah, the behavior will change and we should be good to go. Cool. Congratulations, I'll get any of your changes. Thank you very much. Thank you for your help. No worries. Now, obviously we've done this small change today. Do take a look at the DevTools repo. We'll link that in the description below along with the link to Matias's blog post. Thanks Matias. It's lovely to see you. Thank you for helping us out. And of course it's been lovely to reunite with Surma again to do a little of the Supercharge Reunited. We hope you're all doing really well. We know it's challenging times for many of us at this point in history. It's a very strange addition. It is a point in history, isn't it? It certainly is. It's a remarkable point in history. Not necessarily a good remarkable, but it is one all the same. So we hope this has given you a little bit of a peek behind the curtain, give interesting insight into what we, well, certainly what I do with my days and now apparently what Surma's doing with his days as well. So I guess with that all said, we'll see you on the flip side. On the flip side. Yes. See you then. See ya.