This is the second of two posts about devtools tricks; these are sourced from a conference talk I attended in early November as well as from other things I’ve picked up across the years.

In the first post we covered:

  • Time functions with console.time() and console.timeEnd()
  • Watch any DOM element for changes
  • Monitor any function in the browser’s context

In this post, we’ll cover:

  • Edit any website WSYWIG style
  • Record and replay any user actions
  • Throttle only specific network requests

So without further ado, let’s dive in.

  1. Edit any website WYSIWIG style

    I love messing around with the DOM on the Elements tab. What would it look like if I removed this class from this element? What happens if the text overflows its container on this page? These are all things you can do by manually editing the node you care about on the Elements tab, but it can be a little fussy. I recently learned that you can make the entire page editable. By running document.body.contentEditable = true in the console…well, look at this nonsense:

    I imagine this would be slightly useful for testing UI edge cases, and very useful for entertaining middle schoolers.

    Source: Mindi Weik, who showed me a preview of a talk that included this tip – her talk is not online anywhere as far as I’m aware.

    Support: All browsers

  2. Record and replay any series of actions.

    I’ve truly always just ignored this tab, but if you jump into the Recorder tab, hit record, take any series of actions on a site (clicking buttons, navigating, entering text in forms), and then stop recording, you can then replay those actions, share them with another person, and even generate code for many popular testing frameworks.

    During Mike’s session, some attendees were really excited about the possibility of catching an “unreproducible” bug by recording the steps to generate the bug and simply replaying the actions repeatedly until the bug appeared; I was excited about getting React Testing Library code that would finally convince my colleagues that writing FE tests are worth the effort :) To my disappointment (and complete lack of surprise), however, the code output by the recorder isn’t up to my standards; it tends toward hyper-specific selectors (ex: #story > section > div:nth-child(3) > div > div:nth-child(3) ) rather than how I prefer to write tests, using more semantic selectors.

    I still think the generated code could be useful as a starting point, but even if I never use that, I can definitely imagine a scenario where I send a colleague a bug report that says “Run this recording and see if you see the same bug I do…”

    Source: Mike Rapa

    Support: Chrome for sure; Firefox doesn’t seem to have a record-and-replay function (it does allow you to record for performance analysis, which is different).

  3. Throttle specific URLs.

    Instead of throttling the browser’s connection speed overall, to simulate your end user being on a slow network, you can now tell Chrome to throttle or block only certain resources, to simulate what happens if a third-party API goes down or is overwhelmed.

    This is only available in the Chrome Canary release, but will hopefully make its way into a general release in the next few months. DebugBear has some useful examples on how to get started now, if you can’t wait. There is an example of how to throttle an individual request as well as how to do wildcard throttling.

    Source: DebugBear and Javascript Weekly

    Support: Chrome only