Esteban Herrera Family man, Java and JavaScript developer. Swift and VR/AR hobbyist. Like books, movies, and still trying many things. eherrera.net

What’s new in DevTools (Chrome 85)

3 min read 1012

There’s no doubt DevTools is one of the most useful tools we could use when developing and testing web applications. In Chrome 85, DevTools added several improvements, such as:

  • The Timing tab of the Network panel now includes respondWith events, which record the time before the service worker fetch event handler runs to the time when the promise is settled (issue #1066579)
  • In the Console settings, the Group similar toggle now applies to duplicate messages, and the Selected context only setting in console settings is now persisted (issues #1082963 and #1055875)
  • The Manifest panel now shows warnings for app shortcuts if the app icon doesn’t have the correct size or is not square (issue #955497)
  • Consistent display of the computed pane across multiple viewport sizes (issue #1073899)

These are helpful changes, but in this post, I’m going to review the changes related to style editing and new JavaScript features, as well as changes in the Source and Performance panels.

Most likely, by the time you read this, Chrome 85 will be the mainstream, stable version. At the time of this writing (July 2020), you can only get Chrome 85 by downloading the development version of Chrome. You can learn more about Chrome’s release versions on the page about Chrome release channels.

Style editing for CSS-in-JS frameworks

Editing code or styles in place to see the changes in real time is one of the most useful features of DevTools.

When working with CSS styles, you have the option to manipulate CSS rules programmatically using the CSS Object Model (CSSOM) API:

const style = document.createElement('style');
document.head.appendChild(style);
style.sheet.insertRule('#myDiv {background-color: blue; color: yellow}');

However, DevTools didn’t allow you to edit styles created this way.

This has changed in Chrome 85. Starting from this version, you can edit styles built with the CSSOM API, in particular, when using CSSStyleSheet.insertRule, CSSStyleSheet.deleteRule, CSSStyleDeclaration.setProperty, and CSSStyleDeclaration.removeProperty.

This also works for libraries such as LitElement (try it with this example) or React Native for web (try it with this example).

The styles are editable even if they were inserted after DevTools are opened, and this also works with Constructable Stylesheets (at this time, only available in Chrome).

Constructable Stylesheets allows you to create stylesheets by invoking the CSSStyleSheet() constructor, adding and updating stylesheet rules with replace() and replaceSync():

We made a custom demo for .
No really. Click here to check it out.

const sheet = new CSSStyleSheet();
sheet.replaceSync('#myDiv {background-color: blue; color: yellow}');
document.adoptedStyleSheets = [sheet];

Try it here and here.

Support for new JavaScript features

Chrome uses Acorn to parse JavaScript in the DevTools console.

In Chrome 85, Acorn was updated to version 7.3.0 which, among other improvements, adds support for the syntax of the optional chaining operator (?.).

Using the optional chaining operator, instead of having a piece of code like the following:

if (user && user.name && user.name.last)
 lastName = user.name.last.toUpperCase();

You can have just this:

lastName = user?.name?.last?.toUpperCase();

But until Chrome 84, auto-completion for this operator was broken:
optional chaining in chrome 84

Now, property auto-completion in the console works with this operator (user?.), just like if you were using user. or user[:

optional chaining in chrome 85

The other two changes are related to syntax highlighting in the sources panel.

Until Chrome 84, private fields and methods were displayed as white text. In some cases, even the rest of the line was also displayed as white:

private fields before chrome 85

The sources panel uses CodeMirror to show the code.

In Chrome 85, CodeMirror was updated to version 5.54.0. This version improves the parsing of private properties and class fields:

private fields after chrome 85

The last change about new JavaScript features is about the nullish coalescing operator.

Before Chrome 85, pretty-print formatting was broken when the code contained this operator:

nullish coalescing before Chrome 85

But now it’s fixed and the formatting works properly:

nullish coalescing after chrome 85

More changes to the Sources panel

There are other helpful changes to the Sources panel.

Now we have the ability to copy or cut the current line in the editor even if you select nothing.

For this, position the cursor at the end of the line you want to copy or cut and press the appropriated keyboard shortcut:

position the cursor at the end of the line you want to copy or cut and press the appropriated keyboard shortcut

Another improvement is that if you work with WebAssembly files, the editor now displays bytecode (hexadecimal) offsets to display source locations in Wasm modules instead of the line-based locations used for other formats:

the editor now displays bytecode (hexadecimal) offsets

Finally, there are new icons for breakpoints, conditional breakpoints, and log points.

Here’s how they looked before:

breakpoints before chrome 85

Likewise, this is how they looked in dark mode:

breakpoints in dark mode

Now they are more colorful:

multicolor breakpoints in chrome 85

In my opinion, this improves the readability of the breakpoint icons, especially when dark mode is enabled:

chrome 85 breakpoints in dark mode

Performance panel updates

There are two important changes in the Performance panel of DevTools.

About the first one, until Chrome 84, DevTools didn’t show the caching information if a given script was not cached:

compile before

Now the caching information is always displayed in the summary tab, showing a reason why the caching didn’t happen:

compile after

The second change has to do with the times shown in the rules of the recordings.

In previous versions, times were shown based on when the recording started:

times shown in the rules of recording

Notice the timestamp shown for the FCP of the second page, 8907 milliseconds. This is the time when the event happened since the recording was started.

Now, times are relative to where the users navigate:

timestamps in chrome 85

In the above example, the timestamp for the FCP of the second page is 901.1 milliseconds, the time when the event happened after the page was loaded.

Conclusion

In this post, we have reviewed the most important changes of DevTools in Chrome 85. I didn’t review in depth the four changes mentioned at the beginning of the post, but you can learn more about them on this post (feedback to the dev team is also welcomed).

The post also mentions that the Lighthouse panel was updated to use Lighthouse 6.0 in Chrome 85. Luckily, Lighthouse 6.0 was introduced in Chrome 84, we didn’t have to wait until the next version. Check out this post or the release notes for a summary of all the changes that version 6.0 brought.

Finally, remember that you can download Chrome Canary or Chrome’s development version to access the latest DevTools features.

You come here a lot! We hope you enjoy the LogRocket blog. Could you fill out a survey about what you want us to write about?

    Which of these topics are you most interested in?
    ReactVueAngularNew frameworks
    Do you spend a lot of time reproducing errors in your apps?
    YesNo
    Which, if any, do you think would help you reproduce errors more effectively?
    A solution to see exactly what a user did to trigger an errorProactive monitoring which automatically surfaces issuesHaving a support team triage issues more efficiently
    Thanks! Interested to hear how LogRocket can improve your bug fixing processes? Leave your email:

    : Full visibility into your web apps

    LogRocket is a frontend application monitoring solution that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.

    In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single-page apps.

    .
    Esteban Herrera Family man, Java and JavaScript developer. Swift and VR/AR hobbyist. Like books, movies, and still trying many things. eherrera.net

    Leave a Reply