Notes on Google I/O 2023: Browser Debugging

It was fun to see which advanced browser capabilities Google wanted to call out in their I/O conference, but advanced capabilities or not, developers need to test and debug code. I checked into a few sessions about Chrome Developer Tools.

Learn how Chrome DevTools features help developers debug effectively

That title is a pretty big promise covering a huge area, so naturally a 14-minute video couldn’t deliver everything. The title page showed a more modest and accurate title “Reduce debugging friction.”

One thing I noticed when I started working with web frameworks like Angular and Vue is that I can’t find the code I wrote anywhere. Part of this is expected: TypeScript is not directly executed but translated into JavaScript for the browser. But that translated code is buried within a lot of framework code.

To make debugging easier, Chrome team recognizes the reality that what the developer sees in the browser debug window has little resemblance to what they wrote. C developers know well that when things crash into the debugger we’d be looking at optimized assembly code and not our C source code. Debug symbols allow C code to be matched up against their assembly code output, and similarly browsers support “Source Maps” to provide this correlation between “Authored View” (the code developer wrote) and “Deployed View” (the code being executed by browser.)

A few other browser debug features were covered: the ability to mark code to be ignored, useful for decluttering our screen of library code we don’t care about at the moment. Native code debugging concepts like conditional breakpoints are also available in browser debugger. Another breakpoint derivative are “logpoints” which has all the usefulness of adding console.log() into our code without having to modify our code.

There was a brief blurb about a recorder function, whose output can then be used by Puppeteer. I thought this was a great way to document steps to reproduce bugs, making it much less ambiguous than writing text in a bug ticket. A little bit later, I realized this also meant we could incorporate those recorded steps into an automated regression test. Now that would be awesome. And speaking of browser automation…

WebDriver BiDi: The future of cross-browser automation

This presentation gave us a quick overview of browser automation past, present, and future. The future being represented by the WebDriver BiDi browser automation protocol. Still in development, but on track to be a cross-browser solution of the future. (Not just on Chrome.) I’ve barely dabbled in Selenium, but I knew enough to understand bidirectional communication between the test host and browser under test will open up a lot of benefits to make tests more consistent and waste less time waiting.

Build better forms

Here’s another session with a title far more grandiose than the actual topic. I have an alternate title: “How to make your site work with Chrome Autofill.” There’s more than Google’s self-interest at hand, though. A form crafted so a Chrome autofill recognizes its semantics also means the browser accessibility tools would understand it as well. Two birds, one stone. Most of this session boils down to following standardized form autocomplete hints, and Chrome developer tools to help you get there. I’ve barely done any web development and I’ve already learned a dislike for how complex and annoying forms can be. Every framework tries to make forms less annoying and I’m sure Angular has something to offer there but first I want to see what’s new and shiny in Angular.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s