Chromium Blog: devtools

Debugging Websites in Chrome for iOS

Monday, March 25, 2019

Debugging web pages displayed in Chrome for iOS has always required building the project from source because the release version of WKWebView does not support Safari Remote Debugging. To help bridge the gap of missing developer support, we added the chrome://inspect page in M73 to locally view JavaScript logs. While building Chrome for iOS from source is still the best way to fully debug web pages, we hope that this tool will make it easier to troubleshoot some problems. Background When building Chrome for iOS from source, Safari Web Inspector can be used to debug a web page rendered in Chrome. However, this takes a non-trivial amount of effort which includes setting up a Chromium checkout, installing a current version of Xcode, and waiting for the build to complete. Additionally, a Mac with enough disk space to hold the code and tools is required. This barrier to debugging has led to bugs being filed for specific website failures on Chrome for iOS.
These bugs can be difficult to diagnose as they are generally based on a single failure case. Chrome developers most likely don’t know the website application well enough to fully understand what is causing the bug. Often, the reporter has even spent time to build a dedicated test page to more precisely understand the issue. The lack of debugging tools require developers to come up with alternative methods in order to debug their websites. Of course, nothing is wrong with filing bugs, and we certainly don’t want to discourage it, but we do want to improve the web developer experience. In-app JavaScript Console Enable JavaScript log collection by navigating to chrome://inspect in Chrome for iOS and leaving that tab open to collect logs. In another tab, reproduce the case for which you are interested. Then switch back to the chrome://inspect tab to view the collected logs. (Log collection will stop if the chrome://inspect page closes or navigates and logs will be lost as they are not persisted.)

Posted by Mike Dougherty, Chrome Engineer on iOS

10 Years of Chrome DevTools

Thursday, September 6, 2018

* { line-height: 1.38 !important; white-space: initial !important; } ul { font-size: 11pt !important; } li { line-height: 1.38 !important; } img { margin-bottom: 0 !important; } i { text-align: center !important; } Chrome is turning 10! Thank you for making the web development community so open, collaborative, and supportive. DevTools draws inspiration from countless other projects. Here’s a look back at how DevTools came about, and how it’s changed over the years.

In the beginning, there was Firebug Imagine for a moment that browsers didn't ship with developer tools. How would you debug JavaScript? You'd basically have 3 options:

Sprinkle window.alert() calls throughout your code.

Comment out sections of code.

Stare at the code for a long time until the JavaScript gods bless you with a solution.

What about layout issues? Network errors? Again, all you could really do is conduct painstaking experiments in your code. This was the reality of web development up until 2006. Then a little tool called Firebug came along and changed everything.

A screenshot of Firebug's Net panel, taken from Saying Goodbye to Firebug (source and license)

Firebug was a Firefox extension that let you debug, edit, and monitor pages in real-time. As a web developer suddenly you went from having no visibility into your pages to having what are essentially the core features of modern developer tools. The ability to understand exactly why Firefox was behaving as it was unleashed a flood of creativity on the web. Without Firebug, the Web 2.0 era wouldn't have been possible.

WebKit Web Inspector
Around the same time as Firebug’s launch, a few Google engineers started working on a project which would eventually lead to Chrome. From the start, Chrome was a mashup of different code libraries. For rendering the Chrome engineers opted for WebKit, which is the open-source project that still powers Safari to this day. An added bonus of using WebKit was that it came with a handy tool called the Web Inspector.

A screenshot of the Web Inspector, taken from Web Inspector Redesign (source and license) Like the Net panel of Firebug, the original Web Inspector probably looks familiar. Much of its functionality lives on to this day as the Elements panel in Chrome DevTools. Web Inspector launched a few days after Firebug, and Safari was the first browser to bundle developer tooling directly into the browser.

The "Inspect Element" era
Chrome brought many innovative ideas to the browser ecosystem, such as the omnibox that combined search and the address bar, and a multi-process architecture that prevented one hanging tab from crashing the entire browser. But the innovation we like the most was providing developer tools in every build to every user, exposed with the click of a mouse.

"Inspect Element" in 2010
Before Chrome, developer tooling was an opt-in experience. You either had to install an extension, like Firebug, or enable some flags, as is still the case in Safari today. Chrome was the first browser to make developer tooling accessible from every browser instance. We'd like to claim that we had a grand vision for creating a developer-friendly browser from the start, but the reality is that Chrome had a lot of compatibility issues in its early days (which makes sense, since no one was building for it) and we needed to give web developers an easy way to fix these issues. Web developers told us that it was a useful feature, and we kept it.

The mobile era

For the first few years of the DevTools project, we essentially added chapters to the stories that Firebug and Web Inspector started. The next big shift in how we approached DevTools happened when it became clear that smartphones were here to stay.

Our first mission in this brave new world was to enable developers to debug real mobile devices from their development machines, which we call remote debugging. DevTools was actually well-positioned to handle remote debugging, thanks to another consequence of Chrome’s multi-process architecture. Early on in the DevTools project we realized that the only way a debugger could reliably access a multi-process browser was through a client-server protocol, with the browser being the server, and the debugger being the client. When mobile Chrome came around, the protocol was already baked into it, so we just had to make the DevTools running on your development machine communicate with the Chrome running on your mobile device over the protocol. This protocol still forms the backbone of DevTools today, and is now known as the Chrome DevTools Protocol.

Remote Debugging

Remote debugging was a step in the right direction, and to this day is still the primary tool for making sure that your sites behave reasonably on real mobile devices. Over time, however, we realized that remote debugging could be a bit tedious. When you're in the early phases of building out a site or feature, you usually just need a first-order approximation of the mobile experience. This prompted us to create a set of mobile simulation features, such as:

Precisely emulating the mobile viewport, simulating touch-based input and device orientation.

Throttling the network connection to simulate 3G and CPU to simulate less-powerful mobile hardware.

Spoofing user agent, geolocation, accelerometer data and more.

We collectively refer to these features as Device Mode.

An early prototype of Device Mode

Device Mode in 2018

The performance era

While the mobile era unfolded, big apps like Gmail were pushing the limits of the web's capabilities. Gmail-scale bugs called for Gmail-scale tools. One of our first major contributions to the tooling ecosystem was to show a play-by-play breakdown of exactly everything that Chrome had to do in order to display a page.

The original Timeline panel, as announced in Do More with Chrome Developer Tools

The Performance panel in 2018

These tools were a step in the right direction, but in order to spot optimization opportunities you needed to learn the nitty-gritty details about how browsers work and sift through a lot of data. Lately we've been building on this foundation to provide more guided performance insights. The new Lighthouse engine powers the Audits panel, and is also available as a Node module for integration with CI systems.

Performance suggestions in the Audits panel

The Node.js era

Up until 2014 or so, we mainly thought of DevTools as a tool for building great experiences on Chrome. The rise of Node prompted us to rethink our role in the web ecosystem.
For the first few years of Node's existence, Node developers were in a situation similar to that of web developers before Firebug, or Gmail developers before the Timeline panel: the scale of Node apps outpaced the scale of Node tools. Given that Node runs on Chrome's JavaScript engine, V8, DevTools was a natural candidate to fill the gap. Support for debugging Node with DevTools landed in 2016 and includes the usual DevTools features, such as breakpoints, code stepping, blackboxing, source maps for transpiled code, and so on.

Node Connection Manager

The DevTools protocol ecosystem

The name Chrome DevTools Protocol (CDP) suggests an API that only DevTools can use. The reality is more general than that: it’s the API that enables programmatic access to Chrome. Over the last few years, we've seen a few third-party libraries and applications join the protocol ecosystem:

chrome-remote-interface provides low level JavaScript access to the protocol

Puppeteer brings it to the next level of abstraction and enables automation of the evergreen headless Chrome browser with modern JavaScript API

Lighthouse automates the process of finding ways to improve the performance and quality of pages

We're excited to see thousands of projects depend on these packages to enable rich interaction with Chrome. If you’re in the tooling or automation business, it’s worth checking out the protocol to see if it opens up any opportunities in your domain. For example, the VS Code and WebStorm teams both use it to enable JavaScript debugging within their respective IDEs.

What's next?

Our core mission is to build tools that help you create great experiences on the web. We very much rely on your feedback to help us determine what products or features to build.

Stay up-to-date on new features with our What's New posts

Propose new features on the mailing list

File bugs in Chromium Bug Tracker

Follow us on Twitter to discover new features and bite-sized workflows

Ask questions on Stack Overflow to get help with using DevTools

Take matters into your own hands and contribute to DevTools

Thank you for creating such a vibrant community. We look forward to another 10 years of building the web with you.

Posted by the Chrome DevTools team

Build smoother web apps with Chrome Developer Tools

Friday, November 16, 2012

flying birdsChrome Developer Toolswe’ve addedthe Frame Mode to our Timeline panelSo, what’s a frame

run JavaScript animations and other event handlers

update CSS animations

recalculate styles and lay out the elements in the DOM

re-paint the updated layers of the page

compose them and present to the user

less than 16.6msIf you are not done by then, you’ll miss the frame

network activity and HTML parsing (blue)

running JavaScript (yellow)

performing style recalculation and layout (violet)

painting and compositing (green)

responsive and interactivadded a warning mark on layouts that were forced, by requesting positional properties

best practicerequestAnimationFrameTom Wiltzius’ articleGoogle Chrome Developers@ChromiumDev
Posted by Andrey Kosyakov, Software Engineer

Do more with Chrome Developer Tools

Tuesday, October 23, 2012

Chrome Developer ToolsDevelop for mobile we launchedUser Agent and dimension overridingtouch event emulationdebug mobile applicationsProfile rendering performance profile Chrome’s rendering performance"Jank Busters"

Preview your log itemslongstanding bugcrbug.com

Play with experimental featureschrome:flags

Snippets (essentially multi-line console on steroids)

Source mapping support for SASS

Native memory profiling

Geolocation / orientation override

FileSystem inspection

Canvas inspection

CPU activity in Timeline

CSS Regions support

feedbackcontribution guideChrome Developer Tools EvolutionGoogle Chrome Developers @ChromiumDev
Posted by Stefano Cazzulani, Product Manager

Make your website faster with PageSpeed Insights

Tuesday, June 12, 2012

Cross-posted from the Google Developers Blog.PageSpeed InsightsChrome Web Store

Native ClientPageSpeed Insights SDKPageSpeed Insights for Chromemailing list
Posted by Libo Song and Bryan McQuade, Software Engineers

Debugging Web Workers with Chrome Developer Tools

Monday, April 30, 2012

Web WorkersChrome Developer Toolsdedicatedshared

chrome://inspectdocumentationGoogle+discussion groupPosted by Yury Semikhatsky, Software Engineer

New developer tools experimental APIs for Chrome extensions

Monday, October 3, 2011

Chrome Developer Tools

your feedback

Use the dev channel of Chrome as the APIs are still under development;

Enable experimental extension APIs using the chrome://flags page;

List experimental in the permissions list of your extension;

Add a devtools_page field to your extension’s manifest, e.g:

{ "name": ... "minimum_chrome_version": "14.0", "devtools_page": "devtools.html", "permissions": [ "experimental" ... ], ... }docssample extensionsPage Speed for ChromiumPosted by Andrey Kosyakov, Software Engineer

Chrome Developer Tools: Put JavaScript memory under control

Friday, May 27, 2011

Task Manager

Memory GraphTimeline panelopen Developer Tools

The most functional tool in controlling JavaScript memory usage and finding leaks is the new powerful Heap Profiler available in Chrome Dev Channel. To get a heap snapshot, open the Profiles panel in Developer Tools and press the “Take heap snapshot” button:

Snapshots contain every object from the JavaScript heap, so you can explore them in detail and find out how much memory every object of your application consumes. The heap profiler also offers the following features:

snapshots diffing
grouping objects by constructor
calculating retained sizes of objects
showing dominators tree
revealing paths to GC roots or window objects

In addition, the heap profiler takes into account native DOM nodes, and allows you to uncover DOM-related memory leaks.

It is also possible to measure how much JavaScript memory is currently used from within the page itself. You can sample values from the performance.memory window property at different points of your application lifetime. Please note, that the property does not report anything, unless you run Chrome with --enable-memory-info command-line argument.

For a more complete reference on working with the Chrome Developer Tools heap profiler, check out the tutorial.

[1]: How to invoke the context menu in the Chrome Task Manager:

Windows: Right click on any part of the grid;
Linux: Right click on the grid itself;
Mac: Ctrl+Right click on column headers

Posted by Mikhail Naganov, Software Engineer

Remote debugging with Chrome Developer Tools

Monday, May 9, 2011

Run the Chrome instance that you will be debugging remotely with the remote debugging command line switch: chrome.exe --remote-debugging-port=9222 --user-data-dir=remote-profile. It is essential that you use a different instance of Chrome for the remote session and that is why we run it with the --user-data-dir argument.

Navigate to the pages you intend to debug.

Now run a regular (client) Chrome instance and navigate to http://localhost:9222 there.

We implemented the remote debugging infrastructure in the WebKit repository (or as we say “upstream”), so that other WebKit port owners could expose remote debugging capabilities with a minimal effort. See more information on remote debugging in our WebKit blog post. For more information on the remote debugging and Chrome Developer Tools in general, see our documentation page.

Posted by Pavel Feldman, Software Engineer

Chrome Developer Tools: Understanding Stack Traces

Wednesday, April 20, 2011

Google Chrome Developer Tools

Exception call stack. When something goes wrong, you can open the developer tools console. There you’ll find a number of uncaught JavaScript exception messages there. Each message has a link to the file name with the line number you can navigate to. However, there might be several execution paths that lead to the error and it’s not always obvious which one of them has happened. Exceptions in the console are now accompanied with the complete JavaScript call stacks after the developer tools window has been opened.

Pause on exception. The developer tools’ Scripts panel enables you to pause JavaScript execution each time an exception is thrown and inspect its call stack, scope variables and state of your app. You can choose whether to pause only on uncaught exceptions or on all exceptions.

Logging stack traces. Printing log messages to the developer tools console is also very helpful in understanding how your application behaves. Now you can make the log entries even more informative by including associated stack traces. You can instrument your code with console.trace() calls that would print current JavaScript call stack. Moreover, you can check that some invariants are true using console.assert() which prints a full stack trace when its conditional expression passed as first parameter evaluate to false.

Error.stack. Each Error object has a property named “stack” that contains the stack trace.

Handler function for window.onerror. Recently we’ve added support for setting a handler function to window.onerror. Whenever a JavaScript exception is thrown in the window context and is not caught by any try/catch block, the function will be invoked with the exception’s message, the URL of the file where the exception was thrown and the line number in that file passed as three arguments in that order. You may find it convenient to set an error handler that would collect information about uncaught exceptions and report it back to your server.

home pageWebKit blog postPosted by Yury Semikhatsky, Software Engineer

Chrome Developer Tools: Back to Basics

Thursday, February 24, 2011

Google Chrome Developer Tools

Network aspects of your web page are now inspected in the Network panel. This gives you access to even more information at a single glance. You can sort and clear data, preserve log information upon navigation and even export network data into HAR format.

All the timing information about your resource loads now comes from the network stack, not WebKit, so timing information now adequately represents raw network timing. You can see detailed timing for different phases of the loading by hovering over the log entry.

We now push raw HTTP headers and status messages into Chrome Developer Tools. As a result, you now see precisely what the browser received from the server and not just how the rendering engine interpreted that information.

Similarly to the old Resources panel, you can see syntax-highlighted resource contents.

CSS sidebar

home pageWebKit blog postPosted by Pavel Feldman and Alexander Pavlov, Software Engineers

Break on UI and network events in Chrome Developer Tools

Monday, December 13, 2010

Chrome Developer Tools

Breakpoints TutorialPosted by Pavel Podivilov, Software Engineer

Google Chrome’s Developer Tools Improve Productivity

Friday, June 4, 2010

At Google I/O 2010 we presented on Google Chrome’s Developer Tools and enjoyed getting the in-person feedback from developers. We wanted to list some of the new and improved features we presented at I/O that set apart our tools in helping developers become more productive.

The Scripts panel now allows editing JavaScript without having to reload the page. Just double-click on the line in the function body while debugging and make your changes. We’ll patch the underlying optimized machine code at run-time and continue the execution. [video]
CPU profiler captures the state of your app at a rate of 1,000 samples per second without modifications to the running optimized machine code. The resulting tree view makes it easy to find out where to focus efforts on speeding up the web app. [video]
The new Timeline panel provides a simple view of the AJAX application execution. It records everything that happens in the browser from JavaScript execution to styles re-calculations and then visualizes it in a simple waterfall with timing information and traces to the source code. See the demo fragment at [video].
The improved Heap profiler can take snapshots of the JavaScript heap, visualize and compare them. This makes finding and fighting memory leaks a much easier task. See the demo fragment at [video].

We also covered a number of general Inspector improvements in the WebKit blog recently. Watch them live in the DevTools panel walk through from the I/O video.

We welcome feedback: to submit a bug or feature request please use the Chromium issue tracker and mention DevTools in the summary.
We hope you like the new improved Google Chrome Developer Tools. Note that some of the features above are only available on Google Chrome’s Dev Channel at this moment. For more info please check out the DevTools site.
Posted by Pavel Feldman, Software Engineer

Chromium Blog