Weird Debugging Tricks the Browser Doesn't Want You to Know

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • SurveyJS - Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • disable-devtool

    Disable web developer tools from the f12 button, right-click and browser menu (by theajack)

  • I've noticed that a lot of websites will try to prevent you from using the debugger. They use various techniques ranging from calling `debugger` every second to entrapped sourcemaps to make debugger features work against you!

    Take a look at disable-devtool [1], it surprises me just how many methods can be used to detect usage of an invaluable tool that should be a user's right to use. These "exploits" should really be patched browser-side, but I don't see any active efforts by browsers to fix this.

    I've created a simple anti-anti-debug extension [2] that monkey-patches my way around these anti-debug scripts. It works fine for now, but I can't imagine it working consistently in the long term once the inevitable arms race begins.

    How can we get Google, Mozilla, etc... to care about dev tool accessibility?

    [1]: https://github.com/theajack/disable-devtool

  • Anti-Anti-Debug

    Be able to use developer tools again on user-hostile websites

  • SurveyJS

    Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

    SurveyJS logo
  • devtools

    Replay.io DevTools (by replayio)

  • Replay's founders originally worked as engineers on the Firefox DevTools (and in fact our debugger client UI started as a fork of the FF Devtools codebase, although at this point we've rewritten basically every single feature over the last year and a half). So, the original Replay implementation started as a feature built into Firefox, and thus the current Replay recording browser you'd download has been our fork of Firefox with all the recording capabilities built in.

    But, Chromium is the dominant browser today. It's what consumers use, it's devs use for daily development, and it's what testing tools like Cypress and Playwright default to running your tests in. So, we're in the process of getting our Chromium fork up to parity with Firefox.

    Currently, our Chromium for Linux fork is fully stable in terms of actual recording capability, and we use it extensively for recording E2E tests for ourselves and for customers. (in fact, if you want to, all the E2E recordings for our own PRs are public - you could pop open any of the recordings from this PR I merged yesterday [0] and debug how the tests ran in CI.)

    But, our Chromium fork does not yet have the UI in place to let a user manually log in and hit "Record" themselves, the way the Firefox fork does. It actually automatically records each tab you open, saves the recordings locally, and then you use our CLI tool to upload them to your account. We're actually working on this "Record" button _right now_ and hope to have that available in the next few weeks.

    Meanwhile, our Chrome for Mac and Windows forks are in early alpha, and the runtime team is focusing on stability and performance.

    Our goal is to get the manual recording capabilities in place ASAP so we can switch over and make Chromium the default browser you'd download to make recordings as an individual developer. It's already the default for configuring E2E test setups to record replays, since the interactive UI piece isn't necessary there.

    Also, many of the new time-travel-powered features that we're building rely on capabilities exposed by our Chromium fork, which the Firefox fork doesn't have. That includes the improved React DevTools support I've built over the last year, which relies on our time-travel backend API to extract React component tree data, and then does post-processing to enable nifty things like sourcemapping original component names even if you recorded a production app. I did a talk just a couple weeks ago at React Advanced about how I built that feature [1]. Meanwhile, my teammate Brian Vaughn, who was formerly on the React core team and built most of the current React DevTools browser extension UI, has just rebuilt our React DevTools UI components and started to integrate time-travel capabilities. He just got a working example of highlighting which props/hooks/state changed for a selected component, and we've got some other neat features like jumping between each time a component rendered coming soon. All that relies on data extracted from Chromium-based recordings.

    [0] https://github.com/replayio/devtools/pull/9885#issuecomment-...

    [1] https://blog.isquaredsoftware.com/2023/10/presentations-reac...

  • _inject

    Javascript Code Injection for Debugging

  • I wrote a tool to do that about 10 years ago. You still need to modify it a bit but you get a big bang for your buck

    https://github.com/kristopolous/_inject

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts