9 ms·

Debugging tricks in the browser

646 points by bkudria 3y ago

Inviz 3y ago
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
thrdbndndn 3y ago
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.
- kossTKR 3y ago
  I would like to know this as well. A tree overview of all nested functions and objects with a search function that quickly jumps to that place, and maybe even let you call that function with data from state?
- selfmodruntime 3y ago
  You can use `trace` to trace the call stack but I don't know of any way to walk back up the call stack.
- dackerlunghack 3y ago
  [dead]
- gear54rus 3y ago
  Do you want to have this in Tampermonkey script ONLY or not necessarily? You can use ResourceOverride addon to simply replace the 100k script with your own script that is almost the same but also assigns the function you need to window.myFn or something. There it can just be picked up by TM.
  - thrdbndndn 3y ago
    Thanks for the suggestion, but the goal is to just use this function in my own code (which has lots of other things going on). I guess it technically can be done by modifying the existing JS in-place, but doing so with a very large, minified JS would be a nightmare in term of maintenance.
    - danShumway 3y ago
      To parent off of GP, I've run into this recently while working on some webextension code and I'm thinking my solution is going to be to monkey-patch the script, but merely to expose a reference to the object/function in question. So TLDR don't monkey-patch a giant minified source file with a bunch of your own code. Monkey-patch the function just enough to get it to be exposed globally with its context, and then have your code separately reference it. This is still fragile (unless you have a stable entry point with regex or something, which is not completely certain to exist, it'll likely break whenever the script changes), and is still not ideal, and I'm still thinking a bit to see if I can do anything better, but I suspect it's more stable than trying to access the function directly by coding the path and should be a great deal simpler as well since it will work even if the function/context is in a closure. ---- Of course, you might be lucky and there might actually be a way to get at the function. For example, I am separately looking into seeing if I can figure out a clean way to reliably look for imports exposed through a webpack bundle, since those are exposed globally and if you can find the paths reliably you should be able to get access to any of the imports (although you still won't have access to the closures). I haven't made much progress on it though, mostly because it's kind of frustrating to work on. ---- There is also the possibility (although I suspect it would get very messy very quickly, and I'm not sure of current browser support) that you could theoretically maybe rig something together with `function.caller` (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/caller https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...), possibly patching the minified source file merely to remove "use strict". I have not messed with `caller` in probably close to a decade at this point, so I make no promises at to whether it still works at all :) but... in its heyday before we realized how wildly insecure it was, it did allow reconstructing the stack from a function in-code in some situations.
- alex7734 3y ago
  The browser does not know the path. Also, if the function (or one of its parents) is in a closure, there may not even be a path to the function from window. If you're sure the function is reachable from window you can search for it recursively: (function () { function search(prefix, obj, fn, seen = null) { if (!seen) seen = new Set(); // Prevent cycles. if (seen.has(obj)) return false; seen.add(obj); console.log('Looking in ' + prefix); for (let key of Object.keys(obj)) { let child = obj[key]; if (child === null || child === undefined) { } else if (child === fn) { console.log('Found it! ' + prefix + '.' + key); return prefix + '.' + key; } else if (typeof child === 'object') { // Search this child. let res = search(prefix + '.' + key, child, fn, seen); if (res) { return res; } } } return false; } // For example: let fn = function() { alert('hi'); } window.a = {}; window.a.b = {}; window.a.b.c = {}; window.a.b.c.f = fn; return search('window', window, fn); })();
  - thrdbndndn 3y ago
    Yeah it's reachable (in unsafeWindow for user script), I eventually find it by something similar. In your example, you already has a reference of `fn` to use, which isn't the case for my userscript (if I have a reference, I would just use it!). I have to search based on the features in plain text of the function (using some regexes on `fn.toString()` to check how the arguments look like).
    - alex7734 3y ago
      The idea is that you use a breakpoint somewhere where you have a reference to the function to see it then paste the search() function in the debugger console and call it to find it in window
      - thrdbndndn 3y ago
        Oh I got it now. Thanks! Will try next time.
- Zecc 3y ago
  Have you tried accessing `arguments.callee`[0]? It is unfortunately deprecated and might throw an error. I've never tried it myself as I rarely use breakpoints in the debugger. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments/callee
Mizza 3y ago
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?
- 0000000000100 3y ago
  You can do some solid debugging with NodeJS if you use the VSCode dev tools. Just add it as a debugging option and you can add breakpoints and step through functions. Works pretty great, JavaScript is pretty nice to debug since everything is incapsulated inside an object for the most part.
- madeofpalk 3y ago
  It does. `node --inspect-brk`. You can connect to it with VS Code or Chrome dev tools. The tricky part is whether there's build tooling infront of just the nodejs command, like converting typescript or something like that. But if you run `node`, then it's pretty easy. Its debugging REPL is just the javascript console itself.
  - Mizza 3y ago
    I looked into that a little bit, but I've got this TS transpiling crap to deal with as well, and I don't want to lose my live code reloading. I guess I'll try again when I find the time. Was hoping there was some 3rd party package I could use to just drop in and set a trace. Thanks.
    - connor4312 3y ago
      That should work fine in the vscode debugger, you just want to make sure that the transpiler you're using is generating sourcemaps. Generally they do by default. If you have issues, open a github issue and I'll fix it :)
- 3y ago
lewisjoe 3y ago
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.
- beebeepka 3y ago
  Absolutely. It's not perfect but it sure beats the debugging nodejs with vscode experience a fellow developer was pushing. I would take the console over this hell.
  - pyrolistical 3y ago
    I don’t know if you are making the implication that you could use chrome devtools to debug nodejs, so I’m making it explicitly clear you can! https://nodejs.org/en/docs/guides/debugging-getting-started https://nodejs.org/en/docs/guides/debugging-getting-started
- civilitty 3y ago
  Shout outs to the people behind the Firebug extension which really kicked browser devtools into high gear.
  - sroussey 3y ago
    One of things about Firebug in particular was how you had one thing like a DOM node and you could inspect it in different ways. Like the element panel or an object inspector in console. I worked hard to open this to extensions as well. And it worked for subpanels as well. Maybe I’ll offer up a patch for chrome devtools, but it’s been a while since I’ve made a PR there and it was pretty modest.
- OOPMan 3y ago
  What in particular do you feel is so special about the JS debugging experience? I've done a lot of debugging on Python, Java and C++ over the years and never felt like I was missing tools (although I certainly met plenty of people that were ignorant of their options in this regard...)
elpachongco 3y ago
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?
BMorearty 3y ago
Under the section "Debugging Property Reads": how would you convert `{configOption: true}` to `{get configOption() { debugger; return true; }}` using a conditional breakpoint?
- altano 3y ago
  That’s not under the conditional breakpoint heading. You would just override the value to be a getter in the console, or you could even change it in your source code if you have write access.
  - BMorearty 3y ago
    Thanks, I know I could do it in the console or the original source. But I was referring to the fact that the sentence in the post says to convert it to a getter "either in the original source code or using a conditional breakpoint."
    - altano 3y ago
      Oh! I understand the question now. You can put any expression into a conditional breakpoint, so anything you can do in the console you can do in a conditional breakpoint. So, if you're doing this sort of thing once, you can just type it into the console and you're golden. But if you want to modify a stack local variable over and over again every time it is initialized, it's much easier to do in a conditional breakpoint because then it will happen every time that line of code runs, and your debugger never has to pause. (see https://alan.norbauer.com/articles/browser-debugging-tricks#changing-program-behavior https://alan.norbauer.com/articles/browser-debugging-tricks#...)
      - BMorearty 3y ago
        Got it! Thank you for the explanation.
timcavel 3y ago
[dead]
temporallobe 3y ago
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.
- ethbr1 3y ago
  It's a joke title.
  - lovepronmostly 3y ago
    [flagged]
- chii 3y ago
  > I wish more back-end languages had this experience. the jvm debugging experience is pretty good imho. It's the compiled languages that have a poor experience with debugging - try injecting code to execute in a c debugger! It's hard as hell to do!
  - bpye 3y ago
    You know the tooling leaves something to be desired when editing instruction bytes is the best option to NOP out an assert - for example.
    - saagarjha 3y ago
      Generally a conditional breakpoint is good enough to do this (though perhaps not very fast).
  - jeroenhd 3y ago
    > try injecting code to execute in a c debugger! It's hard as hell to do! I mean, theoretically, not really? Allocate a page RW, put in some compiled code, remap as R+X, redirect execution there, return code execution to where it was. Jumping through those hoops will be more expensive when you use the debugger like that (you'd need to hot patch some kind of jump statement to circumvent that) but it's not exactly impossible. Things become difficult when the compiler starts optimizing out code, because the debugger would need to keep track of everything, but I don't see why it'd be technically impossible to do so. Executing code in a C debugger is basically how modern reverse engineering works, it's a lot harder than in other languages but it's certainly possible.
adamnemecek 3y ago
`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”.
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
- chrismorgan 3y ago
  To be honest, this might be one they’d be justified in not wanting you to know. Crazy indeed. Chromium-only, I presume.
  - adamnemecek 3y ago
    Haha, I agree. They do seem to have some strange restrictions on this. E.g. When you evaluate it the function returns undefined but it also outputs the array underneath. You can right click and save it to variable. I think the point of this so that you cannot assign the output programmatically, there has to be a person who saves it to a variable by right clicking.
    - chrismorgan 3y ago
      I think it’ll be because for architectural reasons it can’t return a value synchronously, combined with historical ergonomic reasons. I don’t know when it was introduced, it’s possible that originally it could be synchronous and only subsequent V8 changes prevented that. Probably it landed before you could use `await` in the console, and they decided that made the ergonomics of Promising it too bad for the typical use case (though now you could write `await queryObjects(Function)` if it worked that way). All I know is that the documentation at https://developer.chrome.com/docs/devtools/console/utilities/#queryObjects-function https://developer.chrome.com/docs/devtools/console/utilities... says it returns an array of objects, which is patently false. I can’t see any reason for preventing assigning the output programmatically.
Jerrrry 3y ago
>>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.
- darekkay 3y ago
  That's one of my most used bookmarklets: https://darekkay.com/blog/debugging-dynamic-content/ https://darekkay.com/blog/debugging-dynamic-content/
  - lelandfe 3y ago
    Woah, “Emulate a focused page” is a great tip, too.
  - awalGarg 3y ago
    You can just hit F8 and the debugger will pause at the next instruction. Works in both Chrome/FF.
    - DustinBrett 3y ago
      Neither the bookmarklet or F8 is ideal if you want to retain focus and any other state that you may effect by going and clicking or pressing a key.
    - lelandfe 3y ago
      F8 first causes focus to be lost from the document body. Just tested in Chrome.
- cookiengineer 3y ago
  This is what happens when websites prevent an open Console/DevTools side panel. They basically have a main loop running, inserting a debugger; statement in various places where they're annoying, and they do that at 30FPS / 32ms so that the DevTools become useless because there's no way to "ignore" debugger statements.
Andrews54757 3y ago
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 https://github.com/theajack/disable-devtool [2]: https://github.com/Andrews54757/Anti-Anti-Debug https://github.com/Andrews54757/Anti-Anti-Debug
- deleted 3y ago
  [deleted]
- supriyo-biswas 3y ago
  A simple way to solve this issue is to just deprecate the debugger statement and have people rely on setting up breakpoints manually, or request an explicit opt in into the debugger statement so that random websites don’t hijack it.
  - deleted 3y ago
    [deleted]
  - Andrews54757 3y ago
    That would be helpful, but there are also other methods that don't involve using the debugger. For example, one technique involves periodically printing a custom object to the console with a toString getter. This is programmatically called by the browser only when the devtools are opened. This allows the website to know when you've opened devtools and they will redirect/block/crash your browser in response.
  - no_time 3y ago
quotemstr 3y ago
Don't any browsers support re-style reverse debugging yet?
amluto 3y ago
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?
- kristopolous 3y ago
  I wrote a tool to do that about 12 years ago. You still need to modify it a bit but you get a big bang for your buck https://github.com/kristopolous/_inject https://github.com/kristopolous/_inject You can basically wander around any function context at any arbitrary time and see what happened. It exploits the reference counter to keep the contexts from being destroyed. It was really great back when I did a lot of client side js The killer app version of this would be to open a repl at any context. As it stands it requires a good bit of competency to do it well.
- Zecc 3y ago
  Are you looking for logpoints? https://firefox-source-docs.mozilla.org/devtools-user/debugger/set_a_logpoint/index.html https://firefox-source-docs.mozilla.org/devtools-user/debugg... Edit: just realized this is literally the first thing mentioned in the linked article.
  - amluto 3y ago
    Not really. Suppose I have access to a closure that was created by the invocation of an IIFE. I would like to access variables that are in scope as seen from inside the closure, and I’d like to do this without executing the closure.
- cantSpellSober 3y ago
  Why use IIFEs in JS now that we have block-scoping with let/const and modules to isolate data? (open question)
- deleted 3y ago
  [deleted]
- hddqsb 3y ago
  In Chrome you can inspect your closure (as you clarified in https://news.ycombinator.com/item?id=38226743#38231705 https://news.ycombinator.com/item?id=38226743#38231705) using the "Watch" pane, and then look at its "[[Scopes]]" pseudo-property. I don't think there is a way in Firefox.
rootsudo 3y ago
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?
- lancebeet 3y ago
  I can really recommend following the "What's new in DevTools" series by the chrome team. Clicking a link to read release notes when you're in the middle of something may not seem appealing, but spending 5 minutes to skim through it when a new version is released is well worth your time. There are also digestible videos that are just a few minutes long and will give you a brief overview. While their purpose is to show new features, in my experience you will often gain understanding of the current limitations of the tools as well.
russellbeattie 3y ago
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 https://github.com/dataarts/dat.gui 2. https://codepen.io/russellbeattie/full/kGxaqM https://codepen.io/russellbeattie/full/kGxaqM
- iudqnolq 3y ago
  Even though minified variables appear under the correct name in the sidebar panel in chrome I still get an error that they're undefined in a watchpoint, which is annoying.
- altano 3y ago
  Disable source maps in the debugger. They are likely the source of your frustration and frankly I still do not understand why they are on by default given how bad the experience is of actively debugging with them on.
  - altano 3y ago
    Your comment made me want to scratch this long-standing itch and write-up why you should disable source maps. Check this out: https://alan.norbauer.com/articles/disable-source-maps https://alan.norbauer.com/articles/disable-source-maps
- 20after4 3y ago
  I've had the same frustration. The browsers have such great debugging features, in theory, but they never seem to work reliably. I can't even get all of my breakpoints to reliably hit. Everything seems to work ok when the code is unrolled but as soon as it gets bundled, even if not minified, it seems that a lot of debugger features get broken, at least that's been my experience. Note: I'm not a front-end engineer and I'm probably doing something wrong.
acemarke 3y ago
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 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-javascript 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 https://replay.io/discord
- crtasm 3y ago
  > Once you launch the browser, you will be prompted to sign in with your Google account. What is the reason/need for this?
  - acemarke 3y ago
    Replay takes data privacy seriously. Recordings can be shared, but you control who has access to them, and we need to know who owns each recording. Our user accounts are currently based on Google auth, so you have to log in before recording so we can track ownership.
adr1an 3y ago
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.
- scwoodal 3y ago
  +1. It's easy to drop a 1/0 wherever I want Werkzeug to show up in the browser.
  - whalesalad 3y ago
    lol next time try “assert False” but I guess it’s same same
- agumonkey 3y ago
  does it still requires to have django-extension/runserver_plus ?
  - adr1an 3y ago
    idk if it's a hard requirement, probably not... but I am with it... at a dev-specific settings.py just like Django debug toolbar, to avoid adding a dependency to production ;)
    - agumonkey 3y ago
      Aight, I was just asking because we hit some tiny road bumps with runserver_plus long ago, but it might be worth using it again to shorten debugging time.
- just_testing 3y ago
  I really want to have that experience everywhere, including nose.js and the browser. It is so simple and intuitive

646 points by bkudria 3y ago

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

thrdbndndn 3y ago

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.

kossTKR 3y ago
I would like to know this as well. A tree overview of all nested functions and objects with a search function that quickly jumps to that place, and maybe even let you call that function with data from state?
selfmodruntime 3y ago
You can use `trace` to trace the call stack but I don't know of any way to walk back up the call stack.
dackerlunghack 3y ago
[dead]
gear54rus 3y ago
Do you want to have this in Tampermonkey script ONLY or not necessarily? You can use ResourceOverride addon to simply replace the 100k script with your own script that is almost the same but also assigns the function you need to window.myFn or something. There it can just be picked up by TM.
- thrdbndndn 3y ago
  Thanks for the suggestion, but the goal is to just use this function in my own code (which has lots of other things going on). I guess it technically can be done by modifying the existing JS in-place, but doing so with a very large, minified JS would be a nightmare in term of maintenance.
  - danShumway 3y ago
    To parent off of GP, I've run into this recently while working on some webextension code and I'm thinking my solution is going to be to monkey-patch the script, but merely to expose a reference to the object/function in question. So TLDR don't monkey-patch a giant minified source file with a bunch of your own code. Monkey-patch the function just enough to get it to be exposed globally with its context, and then have your code separately reference it. This is still fragile (unless you have a stable entry point with regex or something, which is not completely certain to exist, it'll likely break whenever the script changes), and is still not ideal, and I'm still thinking a bit to see if I can do anything better, but I suspect it's more stable than trying to access the function directly by coding the path and should be a great deal simpler as well since it will work even if the function/context is in a closure. ---- Of course, you might be lucky and there might actually be a way to get at the function. For example, I am separately looking into seeing if I can figure out a clean way to reliably look for imports exposed through a webpack bundle, since those are exposed globally and if you can find the paths reliably you should be able to get access to any of the imports (although you still won't have access to the closures). I haven't made much progress on it though, mostly because it's kind of frustrating to work on. ---- There is also the possibility (although I suspect it would get very messy very quickly, and I'm not sure of current browser support) that you could theoretically maybe rig something together with `function.caller` (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/caller https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...), possibly patching the minified source file merely to remove "use strict". I have not messed with `caller` in probably close to a decade at this point, so I make no promises at to whether it still works at all :) but... in its heyday before we realized how wildly insecure it was, it did allow reconstructing the stack from a function in-code in some situations.
alex7734 3y ago
The browser does not know the path. Also, if the function (or one of its parents) is in a closure, there may not even be a path to the function from window. If you're sure the function is reachable from window you can search for it recursively: (function () { function search(prefix, obj, fn, seen = null) { if (!seen) seen = new Set(); // Prevent cycles. if (seen.has(obj)) return false; seen.add(obj); console.log('Looking in ' + prefix); for (let key of Object.keys(obj)) { let child = obj[key]; if (child === null || child === undefined) { } else if (child === fn) { console.log('Found it! ' + prefix + '.' + key); return prefix + '.' + key; } else if (typeof child === 'object') { // Search this child. let res = search(prefix + '.' + key, child, fn, seen); if (res) { return res; } } } return false; } // For example: let fn = function() { alert('hi'); } window.a = {}; window.a.b = {}; window.a.b.c = {}; window.a.b.c.f = fn; return search('window', window, fn); })();
- thrdbndndn 3y ago
  Yeah it's reachable (in unsafeWindow for user script), I eventually find it by something similar. In your example, you already has a reference of `fn` to use, which isn't the case for my userscript (if I have a reference, I would just use it!). I have to search based on the features in plain text of the function (using some regexes on `fn.toString()` to check how the arguments look like).
  - alex7734 3y ago
    The idea is that you use a breakpoint somewhere where you have a reference to the function to see it then paste the search() function in the debugger console and call it to find it in window
    - thrdbndndn 3y ago
      Oh I got it now. Thanks! Will try next time.
Zecc 3y ago
Have you tried accessing `arguments.callee`[0]? It is unfortunately deprecated and might throw an error. I've never tried it myself as I rarely use breakpoints in the debugger. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments/callee

Mizza 3y ago

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?

0000000000100 3y ago
You can do some solid debugging with NodeJS if you use the VSCode dev tools. Just add it as a debugging option and you can add breakpoints and step through functions. Works pretty great, JavaScript is pretty nice to debug since everything is incapsulated inside an object for the most part.
madeofpalk 3y ago
It does. `node --inspect-brk`. You can connect to it with VS Code or Chrome dev tools. The tricky part is whether there's build tooling infront of just the nodejs command, like converting typescript or something like that. But if you run `node`, then it's pretty easy. Its debugging REPL is just the javascript console itself.
- Mizza 3y ago
  I looked into that a little bit, but I've got this TS transpiling crap to deal with as well, and I don't want to lose my live code reloading. I guess I'll try again when I find the time. Was hoping there was some 3rd party package I could use to just drop in and set a trace. Thanks.
  - connor4312 3y ago
    That should work fine in the vscode debugger, you just want to make sure that the transpiler you're using is generating sourcemaps. Generally they do by default. If you have issues, open a github issue and I'll fix it :)
3y ago

lewisjoe 3y ago

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.

beebeepka 3y ago
Absolutely. It's not perfect but it sure beats the debugging nodejs with vscode experience a fellow developer was pushing. I would take the console over this hell.
- pyrolistical 3y ago
  I don’t know if you are making the implication that you could use chrome devtools to debug nodejs, so I’m making it explicitly clear you can! https://nodejs.org/en/docs/guides/debugging-getting-started https://nodejs.org/en/docs/guides/debugging-getting-started
civilitty 3y ago
Shout outs to the people behind the Firebug extension which really kicked browser devtools into high gear.
- sroussey 3y ago
  One of things about Firebug in particular was how you had one thing like a DOM node and you could inspect it in different ways. Like the element panel or an object inspector in console. I worked hard to open this to extensions as well. And it worked for subpanels as well. Maybe I’ll offer up a patch for chrome devtools, but it’s been a while since I’ve made a PR there and it was pretty modest.
OOPMan 3y ago
What in particular do you feel is so special about the JS debugging experience? I've done a lot of debugging on Python, Java and C++ over the years and never felt like I was missing tools (although I certainly met plenty of people that were ignorant of their options in this regard...)

elpachongco 3y ago

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?

BMorearty 3y ago

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

altano 3y ago
That’s not under the conditional breakpoint heading. You would just override the value to be a getter in the console, or you could even change it in your source code if you have write access.
- BMorearty 3y ago
  Thanks, I know I could do it in the console or the original source. But I was referring to the fact that the sentence in the post says to convert it to a getter "either in the original source code or using a conditional breakpoint."
  - altano 3y ago
    Oh! I understand the question now. You can put any expression into a conditional breakpoint, so anything you can do in the console you can do in a conditional breakpoint. So, if you're doing this sort of thing once, you can just type it into the console and you're golden. But if you want to modify a stack local variable over and over again every time it is initialized, it's much easier to do in a conditional breakpoint because then it will happen every time that line of code runs, and your debugger never has to pause. (see https://alan.norbauer.com/articles/browser-debugging-tricks#changing-program-behavior https://alan.norbauer.com/articles/browser-debugging-tricks#...)
    - BMorearty 3y ago
      Got it! Thank you for the explanation.

timcavel 3y ago

[dead]

temporallobe 3y ago

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.

ethbr1 3y ago
It's a joke title.
- lovepronmostly 3y ago
  [flagged]
chii 3y ago
> I wish more back-end languages had this experience. the jvm debugging experience is pretty good imho. It's the compiled languages that have a poor experience with debugging - try injecting code to execute in a c debugger! It's hard as hell to do!
- bpye 3y ago
  You know the tooling leaves something to be desired when editing instruction bytes is the best option to NOP out an assert - for example.
  - saagarjha 3y ago
    Generally a conditional breakpoint is good enough to do this (though perhaps not very fast).
- jeroenhd 3y ago
  > try injecting code to execute in a c debugger! It's hard as hell to do! I mean, theoretically, not really? Allocate a page RW, put in some compiled code, remap as R+X, redirect execution there, return code execution to where it was. Jumping through those hoops will be more expensive when you use the debugger like that (you'd need to hot patch some kind of jump statement to circumvent that) but it's not exactly impossible. Things become difficult when the compiler starts optimizing out code, because the debugger would need to keep track of everything, but I don't see why it'd be technically impossible to do so. Executing code in a C debugger is basically how modern reverse engineering works, it's a lot harder than in other languages but it's certainly possible.

adamnemecek 3y ago

`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”.

deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
chrismorgan 3y ago
To be honest, this might be one they’d be justified in not wanting you to know. Crazy indeed. Chromium-only, I presume.
- adamnemecek 3y ago
  Haha, I agree. They do seem to have some strange restrictions on this. E.g. When you evaluate it the function returns undefined but it also outputs the array underneath. You can right click and save it to variable. I think the point of this so that you cannot assign the output programmatically, there has to be a person who saves it to a variable by right clicking.
  - chrismorgan 3y ago
    I think it’ll be because for architectural reasons it can’t return a value synchronously, combined with historical ergonomic reasons. I don’t know when it was introduced, it’s possible that originally it could be synchronous and only subsequent V8 changes prevented that. Probably it landed before you could use `await` in the console, and they decided that made the ergonomics of Promising it too bad for the typical use case (though now you could write `await queryObjects(Function)` if it worked that way). All I know is that the documentation at https://developer.chrome.com/docs/devtools/console/utilities/#queryObjects-function https://developer.chrome.com/docs/devtools/console/utilities... says it returns an array of objects, which is patently false. I can’t see any reason for preventing assigning the output programmatically.

Jerrrry 3y ago

>>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.

darekkay 3y ago
That's one of my most used bookmarklets: https://darekkay.com/blog/debugging-dynamic-content/ https://darekkay.com/blog/debugging-dynamic-content/
- lelandfe 3y ago
  Woah, “Emulate a focused page” is a great tip, too.
- awalGarg 3y ago
  You can just hit F8 and the debugger will pause at the next instruction. Works in both Chrome/FF.
  - DustinBrett 3y ago
    Neither the bookmarklet or F8 is ideal if you want to retain focus and any other state that you may effect by going and clicking or pressing a key.
  - lelandfe 3y ago
    F8 first causes focus to be lost from the document body. Just tested in Chrome.
cookiengineer 3y ago
This is what happens when websites prevent an open Console/DevTools side panel. They basically have a main loop running, inserting a debugger; statement in various places where they're annoying, and they do that at 30FPS / 32ms so that the DevTools become useless because there's no way to "ignore" debugger statements.

Andrews54757 3y ago

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 https://github.com/theajack/disable-devtool [2]: https://github.com/Andrews54757/Anti-Anti-Debug https://github.com/Andrews54757/Anti-Anti-Debug

deleted 3y ago
[deleted]
supriyo-biswas 3y ago
A simple way to solve this issue is to just deprecate the debugger statement and have people rely on setting up breakpoints manually, or request an explicit opt in into the debugger statement so that random websites don’t hijack it.
- deleted 3y ago
  [deleted]
- Andrews54757 3y ago
  That would be helpful, but there are also other methods that don't involve using the debugger. For example, one technique involves periodically printing a custom object to the console with a toString getter. This is programmatically called by the browser only when the devtools are opened. This allows the website to know when you've opened devtools and they will redirect/block/crash your browser in response.
- no_time 3y ago

quotemstr 3y ago

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

amluto 3y ago

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?

kristopolous 3y ago
I wrote a tool to do that about 12 years ago. You still need to modify it a bit but you get a big bang for your buck https://github.com/kristopolous/_inject https://github.com/kristopolous/_inject You can basically wander around any function context at any arbitrary time and see what happened. It exploits the reference counter to keep the contexts from being destroyed. It was really great back when I did a lot of client side js The killer app version of this would be to open a repl at any context. As it stands it requires a good bit of competency to do it well.
Zecc 3y ago
Are you looking for logpoints? https://firefox-source-docs.mozilla.org/devtools-user/debugger/set_a_logpoint/index.html https://firefox-source-docs.mozilla.org/devtools-user/debugg... Edit: just realized this is literally the first thing mentioned in the linked article.
- amluto 3y ago
  Not really. Suppose I have access to a closure that was created by the invocation of an IIFE. I would like to access variables that are in scope as seen from inside the closure, and I’d like to do this without executing the closure.
cantSpellSober 3y ago
Why use IIFEs in JS now that we have block-scoping with let/const and modules to isolate data? (open question)
deleted 3y ago
[deleted]
hddqsb 3y ago
In Chrome you can inspect your closure (as you clarified in https://news.ycombinator.com/item?id=38226743#38231705 https://news.ycombinator.com/item?id=38226743#38231705) using the "Watch" pane, and then look at its "[[Scopes]]" pseudo-property. I don't think there is a way in Firefox.

rootsudo 3y ago

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?

lancebeet 3y ago
I can really recommend following the "What's new in DevTools" series by the chrome team. Clicking a link to read release notes when you're in the middle of something may not seem appealing, but spending 5 minutes to skim through it when a new version is released is well worth your time. There are also digestible videos that are just a few minutes long and will give you a brief overview. While their purpose is to show new features, in my experience you will often gain understanding of the current limitations of the tools as well.

russellbeattie 3y ago

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 https://github.com/dataarts/dat.gui 2. https://codepen.io/russellbeattie/full/kGxaqM https://codepen.io/russellbeattie/full/kGxaqM

iudqnolq 3y ago
Even though minified variables appear under the correct name in the sidebar panel in chrome I still get an error that they're undefined in a watchpoint, which is annoying.
altano 3y ago
Disable source maps in the debugger. They are likely the source of your frustration and frankly I still do not understand why they are on by default given how bad the experience is of actively debugging with them on.
- altano 3y ago
  Your comment made me want to scratch this long-standing itch and write-up why you should disable source maps. Check this out: https://alan.norbauer.com/articles/disable-source-maps https://alan.norbauer.com/articles/disable-source-maps
20after4 3y ago
I've had the same frustration. The browsers have such great debugging features, in theory, but they never seem to work reliably. I can't even get all of my breakpoints to reliably hit. Everything seems to work ok when the code is unrolled but as soon as it gets bundled, even if not minified, it seems that a lot of debugger features get broken, at least that's been my experience. Note: I'm not a front-end engineer and I'm probably doing something wrong.

acemarke 3y ago

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 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-javascript 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 https://replay.io/discord

crtasm 3y ago
> Once you launch the browser, you will be prompted to sign in with your Google account. What is the reason/need for this?
- acemarke 3y ago
  Replay takes data privacy seriously. Recordings can be shared, but you control who has access to them, and we need to know who owns each recording. Our user accounts are currently based on Google auth, so you have to log in before recording so we can track ownership.

adr1an 3y ago

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.

scwoodal 3y ago
+1. It's easy to drop a 1/0 wherever I want Werkzeug to show up in the browser.
- whalesalad 3y ago
  lol next time try “assert False” but I guess it’s same same
agumonkey 3y ago
does it still requires to have django-extension/runserver_plus ?
- adr1an 3y ago
  idk if it's a hard requirement, probably not... but I am with it... at a dev-specific settings.py just like Django debug toolbar, to avoid adding a dependency to production ;)
  - agumonkey 3y ago
    Aight, I was just asking because we hit some tiny road bumps with runserver_plus long ago, but it might be worth using it again to shorten debugging time.
just_testing 3y ago
I really want to have that experience everywhere, including nose.js and the browser. It is so simple and intuitive