 Hey folks, welcome to another episode of Ask Chrome. We're here at the 2019 Chrome Dev Summit and we're ready to answer all of your web development questions live. To get started, we've got a list of questions that we've already asked on Twitter. But don't worry, if you're following along in the live stream, send us a question there and we will do our best to get to it either today or tomorrow. I'm Jason, by the way, and this is not Rob Dodson. Hi, Sam. Hi. Good to see you. Yeah, sadly, Rob could not make it today, so you've got me instead. Well, that's great to have you, Sam. Yeah, without further ado, let's jump straight into our first question. Yeah, so Giuseppe asked about the future of HTML. Now, this is a big topic, as we know, and actually, Nicole Sullivan from the Chrome team and Greg Whitworth from Microsoft will be giving an entire talk about this on day two of the summit. So make sure to check that out. But without preempting their stuff, just a little high level overview of kind of four-part plan really looking into this. And firstly, thinking about accessibility, ways to make the web more accessible by making some changes with HTML and HTML implementations. Stuff like focus outline. Now, this is kind of a little outdated. It doesn't look great. It doesn't work really well anywhere. We have some sort of basic problems like, for example, in Chrome, you have like a blue outline. And well, yeah, if the background is blue, that just doesn't work very well. So we want to be able to improve, in this case, outline without people hacking stuff like getting the whole outline done thing, which is like everywhere on the web now. Not great for accessibility. No, we want to avoid that. We want to avoid that. Thinking also about styling. So we want to provide some new hooks for styling elements. Starting with relatively simpler stuff like checkboxes and radio buttons and then getting into more complex UI like select elements. Stuff like the way you interact with... Imagine if you've got an email app and you want to add email addresses. You get these nice little autocomplete thing of your jigs. And we're thinking about new ways to kind of get really nice behavior with those component parts. Right, so maybe you ship a component on the platform that is basically an email to field or something like that. Yeah, yeah, yeah. Something like that. That would be nice. Yeah. I mean, we've had some great questions from... Yeah, from Giuseppe and others. Thank you. Thank you, Giuseppe. About like new accessibility features. And I mean, like you say, there is some really interesting stuff in the works. So first up, one thing we definitely wanted to talk about is the accessibility object model, the AOM. Now, you know, assistive tech has always had this kind of concept of the accessibility tree. The tree behind the tree. Yeah, yeah, yeah. So for those who don't know this, this is a way to represent the content on a site so that maybe like gives, you know, assistive devices access to the content itself, you know, may not be so obvious from the DOM. Right. Now, what the AOM does is to provide new like developer facing APIs that give, you know, more direct access to like to inspect and manipulate this data structure, the AOM. The kind of core concept here is that, I don't know, you might want an accessibility object model that's different from the DOM. You know, you might want a different structure. You might want to be able to do stuff like add what we're calling virtual nodes for stuff like a rich text editor. Now, you think about this, you're building an app that's say using Canvas. Right. You know, like what does the DOM look like? There isn't one, right? No, we need something different. Now, like, yeah, the accessibility team here were pointing out, you know, you can use fullback content, but, you know, that's just not very pleasant. That's kind of inherently a hack. Cool. So with the AOM, you can create a virtual accessibility tree that describes the content and also can change dynamically, which is really, really cool. You know, that helps assistive technologies announce changes to content and provide like spatial navigation and so on. It's almost like a second DOM. Yeah, yeah, exactly. Yeah, that's super cool. Yeah, so when we reached out to Chrome's accessibility experts, they were super excited about a bunch of other APIs that are coming down the pipe, but the one that caught my attention was focus visible. So focus is sort of obviously an important part of browsing the web, especially when you're using assistive tech. But it turns out that managing focus is extremely hard. And also it's sort of sometimes out of odds with how we want to design things. Yeah. I mean, this is a core part of accessibility, isn't it? Yeah. Focus is a huge deal. It's step zero. So if you think about something like a text field, when you focus on a text field, we have to have a visible indicator because we need to put the cursor in that field. You are going to continue interacting with that field. Versus if you think about a button, oftentimes when you focus a button, it's from clicking the button, and then you're done interacting with the button. So we don't necessarily need to have a permanent visual marker that the button is highlighted. And so focus visible is like focus, but only in cases where we want to keep that focus indicator around. Right. Yeah, so there's a trick that Rob was telling us about when we asked him about this, where if you're on a mobile phone with a soft keyboard and you tap something, if the soft keyboard comes up and stays up, that's something that is going to be focus visible. Yeah, exactly. So we want to persist focus there. If you tap a button on a phone, we don't pull up the keyboard. Okay. Yeah. So that's sort of like the little limerick. Yeah. I thought that was a really interesting way to remember it. Another accessibility concern was providing alternative text for content that is produced in CSS. So we all know, you know, that image tag has an alt attribute. You can provide fallback text there. We don't have alt for CSS, or at least we didn't have it until the CSS alt text API. So this would be if you have like an icon font or images that are being defined in CSS, you could provide fallback text for those images without having to, you know, breach into your HTML to do that. Yeah. Another question we had actually from Pymduit on Twitter. Thank you very much, which is asking me like, I have a draw with nav items that is initially inert. Will its content still get picked up by crawlers since it is semantically hidden? Right. Now, the concept here, right, is a menu that may not be displayed initially until you tap on something like what we might call a hamburger menu icon. Yeah, whatever they call the thing with no name. Anyway, now, like some of you may not know, but HTML recently got a new attribute on HTML element that makes it possible to mark an element as being uninteractive. Right. And, you know, that attribute is inert. Now, from an accessibility viewpoint, this is really useful. Super useful. Yeah, because it makes, it's a way to make parts of the DOM like clearly be avoided for anything that's like acting on behalf of the user. So, you know, the inert attribute just makes this really simple and I think kind of intuitive as a way of marking that content as something that is uninteractive. It's there, but it's not tab navigable or whatever. That's right. So he was asking basically like, if I use the inert attribute, if I do the good thing, is something like Google search or whoever going to pick that up? Yeah, now the good news is that, search will still see your stuff. This doesn't make it go away as far as search crawlers are concerned. And, you know, of course, web crawlers do benefit from semantic markup, but they aim to discover as much content as possible. Right, so if you put your whole navigation in something that's inert, we're not going to not crawl it. That's right. It's still there. Yeah, yeah, yeah. So the answer to your question, Vim, is yes, search crawlers will see stuff even if it's inert. Yeah, continue to use inert. Yeah. Yeah, so I put out a call for some performance questions and I got some really interesting ones. A lot of them from Greg. So thank you, Greg. Thank you, Greg. So he was asking a lot about networking performance and his first question was, with regards to multiplexing in HTTP3, is there an upper limit to shared resource connections? So let's say you had a hundred separate style sheets for a hundred components or something along those lines. Would you face a time penalty or performance penalty in time at first byte or other metrics for having so many style sheets? And this one, it's a pretty easy answer. There is still per request overhead in HTTP3. So the protocol has advanced, we have multiplexing, we can stream things concurrently, but there is still headers in the request and the response for each request that you make. And so HTTP3 reduces the amount of overhead, but it doesn't eliminate it. We can't fully eliminate it. Yeah, a request is a request. Yeah, you still have to have headers. If there's cookies, you still have to send the cookies. So there will still technically be a penalty. It might be that the thresholds that you'd be working with here for like number of style sheets you'd want to ship on a page are higher, which is, it's a useful thing to have in the back of your mind, but they're not gone. So a second one that he asked was, with regards to push headers and resource hints, what are they good for? Do they work? Do they help the user in any specific way? So push headers are pretty useful. There's a new spec called resource hints that essentially lets you ship indicators of resources that you would like the browser to download before you ship the rest of the request. And the primary thing this is useful for is if you are preparing a page, let's say you're doing server-side rendering, but you already know before you're finished the rendering that there's a couple of resources the page is going to rely on. Maybe your CSS that you inlined has some external assets, or you are doing server rendering of a single-page application and you want to start loading your JavaScript bundles. So you can either send a push promise for this in HTTP2 or coming down the pipe with this spec, you can send early hints with a link header that would tell the browser to go out and download that resource. And so this is just a way for you to get those hints out before you start streaming the response and the browser has to start doing rendering work and whatnot. Just sort of moving the entire network of waterfall forward in time. At least that's the goal. Okay, I've got one for you, because I believe you might actually be able to answer it. A question from BitMotions with some long name. Is that actually in their name? Yeah, that's amazing. It's pretty cool. And thanks, by the way, for all these questions on the live stream. So the question here is, what is the longest method name in the browser API? So before I would have said get bound in client rekt, which is long but easy to remember. But no, IG actually just announced a new API that I think takes the cake for this. The API is called is user verifying authentication platform available? Okay. Let me get my head around that. Does what it says on the tin. Yeah, yeah, okay. I sort of read it right to left. Sounds like one of those German things where they take a whole phrase and then get one. Massive portmante, I would. I want it to be that the API has no capitalization. It's just all one way. Yeah. I think it is thankfully capitalized. That's quite impressive though. Oh, wow. I know one thing you were going to talk about actually was just mentioning about the Chrome serial API. Right, yeah. Somebody had asked, can PWAs with ServiceWorker access Chrome.serial API, does this have the same or better ability to handle fast communication and the same sort of conditions that Chrome apps had. And my understanding is that the idea is that the web serial API should be able to handle everything that the Chrome serial API handled. Yeah. And this is really important. It's like we want the web platform itself to have all these great capabilities, not just Chrome. That's a very important constraint that we place on ourselves. So there's, I think there's a talk at Chrome Dev Summit about web serial. Yeah. And I think I actually spotted over in the Sandbox with some web serial stuff. I mean, if you're at the event, and apologies to those who aren't, but there's some really nice demos, but there's actually a codelab that goes with this. And you can do the codelab anywhere. Yeah, exactly. And it's really nice. You work with some components which are pretty easy to come by. Yeah, it's beautiful. Cheap. Cheap. It's the USB cable that you've got sitting on your desktop. Yeah. It's like, yeah. So we'll add a link to that codelab so you can have a go with that. Definitely. Definitely. So one last question. Time for one last question. Yeah, one last question. And, you know, I noticed this on Twitter earlier from Liz. Right. It's actually a question we've been asked a lot. Yeah, this is a super important one. Yeah. We get asked about this like many times. Every day. Every day. At least once or twice. So the question is, where did you get all those sweet sweaters? Right. Yeah. Right. Yeah. So for context, if you did not watch The Opener, you know, Mariko and Paul and Serma. Yeah. They have a lovely matching set. Beautiful matching sweaters. Gorgeous knit sweaters. What we call jumpers. Oh, yeah. Other parts of the world. Sorry, jumpers. Yeah. So the secret here is that Mariko actually knits them herself. She is like a professional knitter. Yeah. She's a machine. She's a knitting machine. You could almost say. Knitting machine. Yeah. Yeah. Yeah. She's a complete pro. She, I'm trying to convince her to knit sweaters for the rest of the team, but I don't really have anything to offer her. Yeah. So, you know, go and buck her. Yeah. Go and buck her. And actually like, we will put a link here. She has an amazing app, which is called Knit. The pattern app. Yeah. It's called Knitlify. That's what you're talking about. Knitlify. Knitlify on the end. And you can use that to take an image and create a knitting pattern with it. Very cool. Which is actually apparently what she used for the stuff that's here. So you two can build your own kind of little dinosaur logo jumper. This is if I had this skill to be able to do knitting. Yeah. Yeah. Which I don't. But I would like to pick up. A minor problem. Yeah. Yeah. Mariko is a, yeah. She's a pro knitter. Yeah. So the first question. Any minutes. We're going to answer. Today comes from Brian who said portals. And then he followed that up with. Okay. I want to know about the devs. I want to know about the status of standardization. I want to know about the objections of accessibility, potential for abuse, lots of different stuff. So portals are a new thing. If you haven't come across them yet, the spec gives a really, really concise definition of what exactly portals are. So I'm going to read it word for word because it's very important. A portal is a browsing context whose portal state is set to portal. I love, I love spec language. It's like, it's like sort of legalese, but only more say. Yeah. Wow. Does that mean? I don't 100% know what that means. Right. So what does that actually mean? So portals are a new navigational primitive. It's sort of like a hybrid between a webpage and an iframe. And so with a portal, you can embed one page into another page. And then you can invoke, I think it's called activate on the portal. And that will promote the embedded page to be a new top level page. So you can totally see this being like useful for a product category page. Let's say you're on like an e-commerce site or something. And then you tap on a preview of some content and you go to that page. Yeah, yeah. I know that it's like quick view or, you know, like quick shop instant. You know, these kind of flashy names. Yeah. Anything to avoid like a full page load, right? Well, yeah, yeah. And then you put a brand name on it. Yeah. Right. So there's a bunch of interesting use cases for portals. We've got embedded widgets, search results pages. There's tons of these. So basically any time when you want to show most of another website or web page inside of your page, but tapping on that embedded content needs to be basically transitioned to the page without blanking the screen or being a jarring user experience, that's probably use case for portal. It's also a potentially compelling feature for navigations within the same website, not just cross websites, which is kind of cool. So portals might give us a way to blur the lines a little bit between what you would think of as like a typical multi-page application versus a single-page application. It's possible that in the future we'll be able to animate between two pages. So you can actually have like completely separate pages that load and unload like a multi-page site, but it's seamless client-side navigation. Right. Yeah, that's cool. Yeah. I mean, unsurprisingly, portals bring with them some challenges for accessibility. You know, one of the first reported issues we've just been looking at this was that like portals aren't keyboard accessible. And now that means that, you know, keyboard navigation users can't actually activate a portal by default. You know, you need to tap or click. Now, I think like it's possible to add event handlers in JavaScript, but this is kind of hacky. You know, it's not a good way of making things work. So we need to make sure that the API, you know, has that stuff in place without these kind of hacks. Also, another, I mean, there are multiple issues here, but if you use the tab index attribute to make the portal elements tab navigable. Oh, great. So you can tab into it. Yeah, yeah. That can actually have the effect of like creating, you know, a tab trap. That sounds terrifying. Yeah, it is. I'm picturing myself surrounded by a lot of tabs. I know, I know. It's like not a bad place. So we're, you know, this is where like focus gets moved into the portal and the user will get stuck. And of course it means, you know, you can't activate the portal. So this is a problem to, you know, we've obviously that a bunch of these things that we're addressing. And the question of abuse, you know, portals are interesting, interesting problem again. So, you know, a couple of kinds of abuse that we need to think of like any feature like this. I mean, just in general, like so many things like overdoing it, just, you know, seeing everything as a potential like portal, like just adding too many portals and image portal. Yeah, yeah. And like, I mean, you know, a portal is embedding like a real page. So like adding a hundred embedded pages is going to be really, really expensive. And it sounds sort of like the advice we're giving to people for portals is similar to what we say for something like intersection observer where it's like they're a great feature. They're really useful. Yeah. Please don't use a thousand of these. Yeah, yeah. But just getting back to accessibility. Kevin asked a question on Twitter about an accessibility feature in the dev tools in Chrome. So he says recently color accessibility was changed and now only checks the current elements BG color. Previously it checked the BG color of its ancestors until it found something not transparent. I assume is there more information on this? Right. Yes, there is. We've actually spoken to Paul Lewis himself who works on the dev tools, which is great. So what this refers to is the DevTools color picker and a bit of context to that. DevTools has to try to make like a best effort when determining the background color. Right. That's not always simple. That's hard. You can imagine. There are situations where you have background images or you have multiple layers where you've got DOM elements on top of each other and so on and so on. Right. So they've had fixed position text with a transparent background over top of an image. Yeah. When I scroll the background color changes. Yeah. Exactly. So what the DevTools did not want to do was display dodgy information. Right. So they kind of took it out in those situations. Now, thankfully, we've just got a fix for that, which Paul is just implementing actually. So even in cases where the DevTools aren't perfectly sure of the background color, they'll still show you the contrast ratio in the UI, except just with like a transparent background. Okay. So the button will still be there? Yeah. It's a little eyedropper or whatever. Yeah, yeah, yeah. It won't be just like where did my ratio go? The picture's gone. Yeah, exactly. Right. Yeah. So Andrew also on Twitter, I think he asked another question earlier. Yeah. He asked, when will PWAs be released in the Play Store? Which is a super interesting question that we have a solution for called Trusted Web Activities or TWA's. Yes. Because Trusted Web Activities is too long of a name. So as we know, web content has been sort of present on the Android ecosystem for a really long time via WebView and other solutions. And TWA's provide a high performance, secure, sort of user choice preserving way to build web apps on the web stack but put them in the Android Play Store. Yeah. So right now you can wrap up your PWA as a TWA and submit that to the Play Store. It can be downloaded and installed just like any Android app. This is a little bit tricky because TWA's take a bunch of different forms. It's not just your app as an Android app. You can mix native UI with web UI and stuff. And so there is a guide written by Peter on web.dev that basically walks you through the approach of taking your PWA and making a perfectly equivalent TWA for it. The one thing to remember with TWA's is it is not just arbitrary web content on Android. There is what we call installability criteria and sort of in short, this means you have to be a valid PWA. So in Lighthouse you get the PWA check mark and you also have to have a performance score of 80. Right. So there's a bar there. Yeah. And we do this because we want to make sure that anything that makes its way onto the Play Store is meeting the same criteria that a user would expect of a native application. So we set a high performance bar. We set a high bar for making sure that the app works offline and effectively. Yeah. Yeah. No, that's great. So that's TWS. Yeah. What people expect from something they see on their home screen. Yeah. It's going to work. Yeah. You're not going to see a dinosaur. Yeah. Yeah. That's great. As fun as that would be. Well, you know, yeah, that's cool too. We love dinosaurs. Anyway, another Andrew question. Will the Shape Detection API be released in M80? So first just some background to this because I really like this API. Anyway, so we've had access to video streams with GetUserMedia since Chrome 21, I think. Wow. And image capture for still images since Chrome 59. Now, the thing is, of course, there are lots of interesting use cases for analyzing the actual content of images. You know, stuff like barcode detection and text processing, which is great. We've actually had computer vision libraries like OpenCV since the last century. JavaScript ports of this. That sounds weird to say. I know. It's crazy. It's the 1900s. Yeah. I looked it up. It's like 1999. Wow. Anyway, so like the ports of this in JavaScript work pretty well. You know, amazing. But, you know, obviously for really fast and efficient image detection, you know, we need to use hardware. Right. So that's where the Shape Detection API comes in. This uses hardware acceleration wherever it can. Sweet. Yeah. For face detection too? Yes, it does. That's right. Yeah. So now this is a little where it gets a little more complex. So the original spec covers also text detection. But this is actually really hard to get right across platforms and character sets. You can imagine. Yeah. For like multiple character sets, multiple different, yeah. Sounds cool. Yeah. Would be amazing. Anyway, the point is it's been moved to a separate spec of its own. Shape detection for stuff like barcodes is actually going to be flagless in Chrome 80, which is fantastic. Sweet. There's a very cool demo, by the way, that our colleague Paul Killen did. It's qr snapper.com. You know, just for detecting QR codes, just works really well. Actually a useful app. Yeah, yeah. No, check that out. Check that out. Okay. So Rick on Twitter asked, can we have an export to JSON option in the context menu of a variable? And so I'm assuming he's talking about inside of Chrome DevTools here. Let's say, I think you give an example here. So you're console.log, response data from an API call, sort of locked in the local variable of whatever it was set. You're really convenient to be able to right-click that and say copy or save as JSON or get in my clipboard or get it on disk. So a lot of people don't realize DevTools has a copy command. It's one of the console built-ins. So you just call copy like a function. It's not in the menu or anything. You just have to know that it's there. So like an Easter egg. Like many things. Yeah. Yeah. So for now, you can right-click on the variable wherever you see it. So in the scripts tab or in the console. Yeah. Click store as global variable. And that will set it as like dollar sign temp one or something. You don't need to care about the name. You can just type copy brackets dollar sign underscore. Remember that? That's almost like pro. Yeah, it is almost like pro. Actually, I think this comes from pro. And it will copy the previous thing in the console to your clipboard, which in this case will be a JSON representation of the variable. Yeah. Copy converts it to JSON internally. So you can sort of do this today. It is not one menu item. It's a little bit of text. Fantastic. Fantastic. Cool. Micro sites on Twitter. Not sure what their name is, but that's their handle. Yeah, that's cool. They asked will Chrome 79 mixed content blocking also affect intranet sites? So they mentioned they heard this thing in December. And then in January, it would start fully blocking insecure content on secure origins. So I actually don't know what the proper timeline is for this, but I'm going to take his word for it. I'm assuming this is the thing that's coming soon. The one thing that we do know is that Chrome has a, let me phrase this correctly, there will be an enterprise policy likely called insecure content setting that will give enterprise admins the ability to keep loading mixed content without the warnings or blocking. You should be radio announcement. That's actually my dream when I was doing that. You can say do it. You can do like those weird warnings that you get coming soon. Yeah. So generally when it comes to future workloads like this, Chrome's, you know, mission is let's provide an enterprise policy that helps with deprecations and removals. And in this case, like if you have an intranet and you are relying on this and you have a separate timeline for when you want to upgrade that mixed content, we'll give you the option to extend that. I think there is a thing as part of all this where we will try to auto-upgrade HTTP content to HTTPS. I have no idea what the constraints are around how that works, but there's something there for that. So it might be that this is less of an issue than it seems like on paper. That's good. That's always good. So yeah, we've had more great accessibility questions today. One from Manoj who asked, would you consider adding an accessibility score that shows up whenever the DevTools in Chrome is opened so that businesses provide time to developers to implement accessibility features? This is a really cool idea. Yeah. You know, like anything that exposes accessibility metrics is a great idea. And to a wider audience. We'd love to see accessibility scores be more prominent when business decisions are being made. We'd love to see those numbers in the boardroom alongside other stats that people have for conversions or sales or even now performance. Yeah, we think about these things as developers. Yeah. But if your C-levels or your business folks or whatever aren't aware that your accessibility score is hurting your website, then how do they make decisions? Yeah. And it's like damaging their business. So obviously Lighthouse, I'm sure you've seen this, has an accessibility score. And that's something you can pull up in the audits tab in the DevTools like today. But you can also access that of course via the APIs and with Lighthouse continuous integration, which is something that Elizabeth and Paul talked about yesterday, day one from Chrome Dev Summit. So do check out their report, their talk about this. We've seen some great examples of this. People using dashboards and making them easily available to people throughout the company. So you get better business visibility and accessibility numbers. So you can see a trend line of your website's accessibility score over time. Yeah, exactly. Another thing to consider would be like, normally with Lighthouse we always talk about Lighthouse and run an audit of your site. But your site is more than one page. And when we do a Lighthouse audit, we're auditing one page. So maybe for you in your continuous integration setup or in your dashboard or whatever it is, when you run Lighthouse and you grab those numbers, maybe it's not just for the homepage. This is my bug bear. Like please when you use Lighthouse, don't just use your Lighthouse on everything. Your homepage, do it. Like if you're on an e-commerce site, use your category pages, your product pages, the checkout flow, everything. Like, you know, it's a great idea to do that. How frustrating would it be to be an assistive tech user and you're shopping. Everything's actually pretty good so far. You've got tab navigation. Everything's working. Yeah, add something to your cart. You go to the cart. Click the checkout button. Yeah. Yeah, yeah. You can't focus the credit card fuel. Now that's interesting because we actually, like what we've often noticed with performance is that what users notice is not necessarily like slow performance, it's performance differences. Right. So you go from like, you see this regularly. You go from a fast homepage to a slow, say category page. Yeah. And that's what users really get frustrated with. Yeah, the picture of the site looks great. Yeah. Yeah, yeah. That's right. So another thing actually we've seen with metrics like accessibility. I mean, which is pretty hardcore, but I like it is, you know, that you display metrics over your website internally. Like in the office, everyone, every time they go to your website actually sees those numbers on the side. I love this idea. Yeah. So, you know, it's literally in your face. I want that for like accessibility, performance, everything. Exactly. That's a great idea. And it's, you know, it's a great way of just getting things beyond engineering. That way when everybody else at your company is browsing the site, they see these things front and center. Yeah. And they see you like make improvements so you like, you know, had impact and things work. Look, invaluable. Yeah, exactly. Yeah. Okay, cool. So Christian asked, is there such a thing as send this link to desktop from your phone, right? We know that there's, you can right click on a tab in Chrome for desktop and say send this to phone. Yeah. Do we have the opposite? And so originally, we were really sad about this question because we thought that the answer was no. Yeah. Turns out that's totally wrong. We were looking in the wrong place. The answer is yes, we have this feature. We do. No one we talked to knew about this, except for the person who implemented it. Yeah. It's always right to know the right people. We go backstage, we ask them, we find out ourselves. Yeah. So on Android, if you tap the share menu, right? The three dot menu, click share. There is a Chrome logo that says send to your devices or at least it would say that except on Android, we truncate the text. So it just says send to. Yeah. Which is a little bit confusing, although it is open-ended. We don't know what device you're sending to. Yeah. So anyway, so you tap that and you click the computer to send the tab to exactly like it does with the phone. That's cool. And it shows up on your computer. Yeah. And I think the Chrome team is working to make it. Yeah. Just to improve the UI you ask for this. But it's there. Yeah. It works really well. Send this document to my computer. Yeah. It's amazing. It works really well. Yeah. We have like, Yeah. We've got a couple of minutes. So we'll actually take like one question we've got here often. I'll do this one about from Elia. Cookies. Yeah. Elia is a brawn, brawn. The question is, is there a way to set a break point on cookies? So it breaks when a cookie is set, changed, deleted, either by HTTP header or via JavaScript. Now in the console, you just showed me this because I thought, Yeah. I was looking at the copy function if I'm honest, and I saw this. No, this is cool. So you can use debug in the console and like pass document.cookie to that. Also, like you were showing me just just before, like in the network tab, it's like has response header set cookie. One of the Easter egg search Yeah. Yeah. Exactly. One of the many magic things inside DevTools. DevTools docs do have things for both of these. But really what you're saying is you can use debug to install a break point for document.cookie. That's right. There's your JS version. Yeah. And then you can use the filter in the search tab of the network panel to get the network version. Yeah. Perfect. That gets you both. Yeah. I mean, just, yeah, thanks again for all your questions. So it's been fantastic. Please feel free to send more questions on Twitter using the Ask Chrome hashtag. And we'll do our best to get responses from the Chrome team. We promise to do that and do stay tuned for more episodes of Ask Chrome that will be coming up in the future. Great. From myself and Sam, thanks for watching and enjoy the rest of the show. Yeah. Thanks very much.