Advanced Javascript and Web Debugging Techniques | Hacker News Reader

Advanced Javascript and Web Debugging Techniques

techblog.badoo.com

113 pointsdmitri198130 comments

One small tip I'd like to add:

Writing code in Conditional Breakpoints - So lets say you want to modify the value of PRICE, but only if ASIN == 'XYZ', then you can write:

    if(ASIN === 'XYZ') { PRICE = 20 }

as the condition for your breakpoint and instead of breaking at that point, the value of price will be changed only for that ASIN. Helped me a lot during involved debugging sessions.

This is a great idea !

The thing I really miss when debugging js (compared to other debuggers) is the ability to skip files when stepping. Seeing the innards of jquery/backbone/underscore is usually no use to me, I only want to look at our site's code.

I know I can get that effect by liberally sprinkling my code with 'debugger;', and could even automate that, but still...

Both Firefox and Chrome allow you to "blackbox" js files of your choice.

https://developer.mozilla.org/en-US/docs/Tools/Debugger#Blac...

http://www.divshot.com/blog/tips-and-tricks/ignoring-library...

Thanks! In my defence, the FF feature only made it into release 19 days ago and the chrome one is still 'experimental'. But great to know this is now available.

That's awesome, thanks.

By any chance, do you also know of a way to exclude jQuery event wrappers from inspection in the "events" part ? Like in this screenshot : http://imgur.com/UaHTrth

This feature is pretty useless due to the fact that libraries wrap event callbacks.

That's something we're working on for Chrome. We'll have something soon.

Very nice, thanks for that.

Chrome's one is a dirty hack, though I admit it works. But ugh, seriously, regexes?

Regex is nice, so you can do something like ignore everything in bower_components\/.* or .*?\.min\.js. I'm not convinced you want to select each file you want to skip manually and one by one. That said, maybe there's a hybrid approach available. Our implementation in Chrome is definitely not final (and it's a little ugly ;) and we're collecting feedback before we iterate further.

The thing I miss is the ability to define custom "breakpoint actions" for tracing without source edition. You can kind-of hack it in by using conditional breakpoints which always evaluate to false, but IIRC it there are situations where it doesn't work right.

Xcode (I'm sure others as well, but I played with that one recently so...) has absolutely humongous breakpoint "options" including silencing repeats (e.g. hit a breakpoint 5 times in a session then skip it) and advanced actions[0], including multiple actions per breakpoint, which is really nice.

[0] in Xcode 5, possible actions aside from a conditional break are executing applescript code, capturing an OpenGL ES frame, executing an LLDB command, logging a message (to the console or to text-to-speech), executing a shell command or playing a sound

An Adobe engineer is working on a patch for Chrome DevTools for this. I agree it's useful. It actually does use the same conditional breakpoint backend, so any stories you have about the not-working-right are very appreciated.

I stupidly didn't take notes (as usual) so I fear I don't have anything to provide right now, but if it's being hashed out in an issue or pull request of some sort I could post it there if I hit it again.

I should add that console.log has its pitfalls - in particular, it will log objects by reference, so if you are doing some manipulation later in a block, the value that may be displayed in the Chrome inspector may reflect a value that was manipulated later on in a block of code.

That's not an issue of console.log, that's an issue of webkit's console.log. Firebug does not exhibit this behavior, for instance.

Perhaps - I think a lesson to be taken though is to be careful about trusting console.log. It threw me into a loop when I first encountered it.

Agreed, I was pulling hair out of my head--convinced for a moment there was no order in the universe until I realized that console.log could time travel.

It appears to me that webkit's logging by reference is actually fuzzy; after some magical amount of time the logged object will be displayed "how it used to be"; but in some cases like

    obj = {foo: 'something bad mwahahhaa'};
    console.log(obj);
    obj.foo = 'something good ;-)';

it will just go ahead and time travel to 'something good' and you will never see the 'something bad'.

however, if you expand the the object in the console (side note, would be nice to have an option to display expanded by default) it doesn't ever time travel and

    obj = {foo: 'something bad mwahahhaa'};
    console.log(obj);
    // some magic amount of time or lines of execution
    obj.foo = 'something good ;-)';

will also not time travel

This is not the case anymore. They fixed this issue sometime back.

I've seen this exhibited as lately as Chrome 30.

Another tricky aspect about console.log is that in IE console.log will crash if you pass certain built-in types to it (I remember it happening with XML Document objects).

console.log(JSON.parse(JSON.stringify(object))) is an easy way to log a deep copy, as long as it doesn't have circular properties (happens with some DOM elements).

When needing a quick console to mobile I have previously used jsconsole[1] with great success. Weinre can be a bit overkill to set up just for logging some simple statements.

[1] http://jsconsole.com/remote-debugging.html

Oh man, weinre is one project that needs love now Adobe has their grubby hands on it.

It's really handy for mobile debugging.

Regarding weinre: Is that any better than attaching desktop Safari to an ios simulator (not sure if it works for a physical device) or desktop Chrome dev tools to a real android device via adb?

In any case, note that that's also a lovely option.

I use it to debug android stock browser without ADB, or USB for that matter. I have a bookmarklet set up so I don't have to add the script to the page. The safari debugger is far superior for mobile safari on iOS, though. Primarily because js debugging in weinre is almost nonexistent in comparison.

I wouldn't call "debugger" advanced, but it is certainly useful.

Didn't know about the DOM breakpoint, though.

Funny, I'm the opposite. I've found DOM breakpoints useful for a while, but I've never heard of `debugger` until now. It seems obvious I guess.

This is very interesting and helpful. Thanks for posting.

the remote debugging is already implemented in both Chrome and Firefox. Opera too as far as I know but it's not as simple as the others.

As far as I know, they all rely on you using their browser on mobile as well?

We faced a problem a few weeks ago, where Chrome for mobile worked fine, but the built in browser on Android phones pre 4.4 had some issues with our web app. Then we needed something else than Chrome to do the remote debugging.

Reply on news.ycombinator.com