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.
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...
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.
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.
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.
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).
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 ;-)';
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.
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.
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.
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:
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.