from Hacker News

Debugging tricks in the browser

by bkudria on 11/11/23, 1:35 AM with 122 comments

• by lewisjoe on 11/11/23, 1:15 PM

  The debugging tools built within the browsers have come a long way in the last couple of decades. I'm a JS veteran and I'm deeply grateful to all the people putting in such efforts to make debugging code in the browser so intuitive.

  Whenever I go to a different zone of development, like backend or a different language, I miss this ecosystem of debugging tools that modern browsers have by default.

• by Jerrrry on 11/11/23, 3:26 AM

  >>setTimeout(function() { debugger; }, 5000);

  This is clever; after all, the only way to beat the recursive turtle stack of chrome debuggers debugging themselves is with the debugger statement.

  sam.pl, of the infamous myspace Sammy worm, used debugging gotcha's to prevent visitors from de-mystifying his obfuscated html homepage.

• by adamnemecek on 11/11/23, 3:09 AM

  `queryObjects` is notably missing. It is a crazy API which returns a list of all objects created by a particular constructor. One can for example get a list of all functions on the heap by doing `queryObjects(Function)`.

  This will return even functions contained in some module that are “private”.

• by russellbeattie on 11/11/23, 4:40 AM

  I can never get watched variables to work. The scoping and updating rules for it are a mystery to me. I assume only global variables can be watched, but even then it never works as I expect, so I end up just flooding the log with values when testing.

  I've thought for years the console should add Data.gui [1] style UI for viewing/testing variable and settings values. You can see it action on this CodePen [2].

  1. https://github.com/dataarts/dat.gui

  2. https://codepen.io/russellbeattie/full/kGxaqM

• by amluto on 11/11/23, 3:52 AM

  I’d like to see a way to access local variables of an IIFE, without breaking into code in the IIFE’s scope. Is there some way to convince the debugger to do this?

• by adr1an on 11/11/23, 7:44 AM

  For the sake of completeness, I can recommend Werkzeug. I use it for Django backend development and it's incredibly useful. It allows me to have "PDB" shell right in the browser whenever and wherever an exception is met.

• by Inviz on 11/11/23, 9:12 AM

  One trick i use all the time is debugging by searching through loaded scripts by UI string:

  1) Go to Network panel, start recording network requests

  2) Open left sidebar and invoke search to type in the code/ui string you want to find

  3) It'll usually find it in some weird bundled js chunk file, click on the result

  4) It opens the network request for that file, now right click anywhere in file and pick "Open in Sources" or something along that line, that jumps to debugger

  5) Now place your debugger statement, this will probably load sourcemaps too

• by Mizza on 11/11/23, 11:49 AM

  I've been a Python/Elixir programmer for a long time and I make heavy use of pdb.set_trace()/IEx.pry().

  Lately, I've inherited a very messy NodeJS backend and have been pulling my remaining hair out working without proper debugging tools. I've gone back to 'console.log' debugging, but it makes me feel like a caveman.

  I can't believe that this whole popular ecosystem doesn't have a proper debugging REPL - can anybody point me in the right direction?

• by BMorearty on 11/11/23, 3:43 PM

  Under the section "Debugging Property Reads": how would you convert `{configOption: true}` to `{get configOption() { debugger; return true; }}` using a conditional breakpoint?

• by rootsudo on 11/11/23, 4:11 AM

  This is something I really need to pick up / is there a dedicated book or study for this or is it just web dev / front end all the way down?

• by quotemstr on 11/11/23, 3:37 AM

  Don't any browsers support re-style reverse debugging yet?

• by elpachongco on 11/11/23, 3:01 PM

  I haven't had the need to use it but I've been thinking if something like the last one `Monitor Events for Element` exists. Glad it does. Although according to the article, it's a Chrome-only feature. I wonder if there are any alternatives for Firefox?

• by Andrews54757 on 11/11/23, 3:35 AM

  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

  [2]: https://github.com/Andrews54757/Anti-Anti-Debug

• by temporallobe on 11/11/23, 3:05 AM

  None of these are weird or something the browser is trying to hide from you, just things that an experienced front-end developer would probably know, although I was not aware of the monitor() command.

  That being said, I am pleasantly surprised at the debugging and development tooling that is built right into most modern browsers. It really does make the UI development experience very powerful. I wish more back-end languages had this experience.

• by acemarke on 11/11/23, 5:06 AM

  I'm going to put in a very relevant self-plug for the tool that I work on.

  I work at Replay.io, and we're building a true "time traveling debugger" for JS. Our app is meant to help simplify debugging scenarios by making it easy to record, reproduce and investigate your code.

  The basic idea of Replay: Use our fork of Firefox or Chrome to make a recording of your app, load the recording in our debugger UI, and you can pause at _any_ point in the recording. In fact, you can add print statements to any line of code, and it will show you what it _would_ have printed _every time that line of code ran_!

  From there, you can jump to any of those print statement hits, and do typical step debugging and inspection of variables. So, it's the best of both worlds - you can use print statements and step debugging, together, at any point in time in the recording. It also lets you inspect the DOM and the React component tree at any point as well.

  I honestly wish I'd had Replay available much earlier in my career. I can think of quite a few bugs that I spent hours on that would have been _much_ easier to solve with a Replay recording. And as an OSS maintainer for Redux, there's been a number of bugs that I was _only_ able to solve myself in the last year because I was able to make a recording of a repro and investigate it further (like a tough subscription timing issue in RTK Query, or a transpilation issue in the RTK listener middleware).

  If anyone would like to try it out, see https://replay.io/record-bugs for the getting started steps to use Replay (although FYI we're in the middle of a transition from Firefox to Chromium as our primary recording browser fork).

  I also did a "Learn with Jason" episode where we talked about debugging concepts in general, looked at browser devtools UI features specifically, and then did an example of recording and debugging with Replay: https://www.learnwithjason.dev/travel-through-time-to-debug-...

  If you've got any questions, please come by our Discord and ask! https://replay.io/discord

• by thrdbndndn on 11/11/23, 10:40 AM

  Probably a good place to ask a specific question about debugging here.

  A few years ago, I was hacking a web bookreader.

  It has a function that is used to decode images (they're encrypted in some way) into canvas, and I want to find it so I can call it directly in my user script to batch download decoded images.

  So I monkey patched `CanvasRenderingContext2D` function, added breakpoint, and found where the the function is defined in the 100k lines of obfuscated JS source code, easily.

  The problem is.. once the page is rendered, the function would be nested in some objects, something like `window.abd.fdsfsd.r2323.fsdfs.fasf.xyy.myfunc`.

  I don't know how exactly I can find the full "path" of the function so I can call it, despite I'm literally pausing inside of it. I eventually got it done, but it was manual and painful.

  So I'm wandering: is there a better way to do it? The browser obviously knows it, it just lacks of a way to tell.