Ok I tried to do what you wanted, since it sounds useful, but with a few caveats. I am currently debugging a site where the trace function in jects an alert that causes a syntax error. if(condition) var x = stuff; else other stuff; I key on the word var as a safe place for me to inject trace code, but this one is not safe. alert("c334"); var x = stuff; Causes a syntax error. Worse, if there wasn't an else clause, there would be no syntax error, and my tracing would just fuck up the way the code works. Not sure what to do about that. Why anybody would put a var variable in the if clause, where it can never be used again, because as soon as you hit else it is out of scope, why anybody would do that I don't know, but it illustrates that my trace injecting code will never be perfect, and sometimes needs some manual cleanup. So we need to deminimize once, then snapshot locally, then trace once, then put the trace js files in place of the previous js files, then manually clean them up in case I injected a syntax error, then use those files forever more for debugging. So I don't want a system where you have to say uvw trace again for different start points etc. Now with all that in mind, the new macro is eval($step+"(location)"); (The original bp and bpl macros are still there.) It respondse to the step level, which is global. $step$lev = 0 do nothing $step$lev = 1 print out the location of where you are $step$lev = 2 activate a breakpoint indicating the current location In the breakpoint you can change $step$lev of course. You can put it back to 0 because maybe you're not interested in the first time you hit this block of code, but maybe the second or third, and sure enough it comes back to life when you get to it again. $step$start turns it on. So in my base file, before the first javascript, I added this It is then silent until it gets to c2682. Then it breaks where it can, and I now break at more points, again, hoping not to inject syntax errors. It's all in startwindow.js line 3340 and maybe you can improve on it; it's a gross mash of perl regular expressions plus the stripping done by tools/uncomment. Not for the faint of heart! The basic idea is to trace or break before var variables, or after function(args) { try { catch (e) { if(condition) { else { for(conditions) { This is designed to work with the code that is produced by the deminimizer, and will probably be a disaster if run on any other kind of code. Even as I write this I'm a little paranoid about if(condition) var x = stuff; with no else clause which will cause no error but the tracing will change the way the code runs; and I wonder if I should get rid of the tracing before var. I don't think you would lose very many trace points, if all the others are working. Usually one of the other lines comes just before the var line, so you wouldn't lose anything, and those lines are safer. Let me know what you think. Well all this is kindof harder to explain than to write, so send me private email or message if you have any questions. Karl Dahlke