Register for this year’s #ChromeDevSummit happening on Nov. 11-12 in San Francisco to learn about the latest features and tools coming to the Web. Request an invite on the Chrome Dev Summit 2019 website

Note: Check what version of Chrome you're running at chrome://version. If you're running
an earlier version, these features won't exist. If you're running a later version, these features
may have changed. Chrome auto-updates to a new major version about every 6 weeks.

Read on, or watch the video version of the release notes below.

Blackboxing in the Network panel

The Initiator column in the Network panel tells you why a resource was requested.
For example, if JavaScript causes an image to be fetched, the Initiator column shows you the
line of JavaScript code that caused the request.

Note: You can hide or show columns in the Network panel by right-clicking the table header.

Previously, if your framework wrapped network requests in a wrapper, the Initiator column
wouldn't be that helpful. All network requests pointed to the same line of wrapper code.

Figure 1. The Initiator column shows that all of the requests were initiated
by line 2 of requests.js

What you really want in this scenario is to see the application code that causes the request.
That's now possible:

Hover over the Initiator column. The call stack that caused the request appears in a
pop-up.

Right-click the call that you want to hide from the initiator results.

Select Blackbox script. The Initiator column now hides any calls from the script that
you blackboxed.

Previewing HTML content in the Preview tab

Previously, the Preview tab in the Network panel showed the code of an HTML resource
in certain situations, while rendering a preview of the HTML in others. The Preview tab
now always does a basic rendering of the HTML. It's not intended to be a full browser, so it may
not display HTML exactly as you expect. If you want to see the HTML code, click the Response
tab, or right-click a resource and select Open in Sources panel.

Figure 6. Previewing HTML in the Preview tab

Auto-adjust zooming in Device Mode

When in Device Mode, open the Zoom dropdown and select Auto-adjust zoom to
automatically resize the viewport whenever you change device orientation.

Local Overrides now works with some styles defined in HTML

Back when DevTools launched Local Overrides in Chrome 65, one limitation was that it
couldn't track changes to styles defined within HTML. For example, in Figure 7 there's a
style rule in the head of the document that declares font-weight: bold for h1 elements.

Figure 7. An example of styles defined within HTML

In Chrome 65, if you changed the font-weight declaration via the DevTools Style pane,
Local Overrides wouldn't track the change. In other words, on the next reload, the
style would revert back to font-weight: bold. But in Chrome 66, changes like this now persist
across page loads.

Caution:Local Overrides can track changes like this so long as the style is defined in
the HTML document that was sent over the network. If you have a script that dynamically adds
styles to an HTML document, Local Overrides still won't be able to detect those changes.

Note: This section is not related to Chrome 66. It's just a bonus tip about an existing feature
that you may find useful.

Back when I created the Get Started With Debugging JavaScript video, some
viewers commented that event listener breakpoints aren't useful for apps built on top of
frameworks, because the event listeners are often wrapped in framework code. For example, in
Figure 8 I've set up a click breakpoint in DevTools. When I click the button in the demo,
DevTools automatically pauses in the first line of listener code. In this case, it
pauses in Vue.js's wrapper code on line 1802, which isn't that helpful.

Figure 8. The click breakpoint pauses in Vue.js' wrapper code

Since the Vue.js script is in a separate file, I can blackbox that script from the Call Stack
pane in order to make this click breakpoint more useful.

Figure 9. Blackboxing the Vue.js script from the Call Stack pane

The next time I click the button and trigger the click breakpoint, it executes the Vue.js
code without pausing in it, and then pauses on the first line of code in my app's listener,
which is where I really wanted to pause all along.

Figure 10. The click breakpoint now pauses on the app's listener code

A request from the DevTools team: consider Canary

If you're on Mac or Windows, please consider using Chrome Canary as your default
development browser. If you report a bug or a change that you don't like while it's still in
Canary, the DevTools team can address your feedback significantly faster.

Note: Canary is the bleeding-edge version of Chrome. It's released as soon as its built, without
testing. This means that Canary breaks from time-to-time, about once-a-month, and it's usually
fixed within a day. You can go back to using Chrome Stable while Canary is broken.