User:GijsKruitbosch/JS Debugging

Got comments? Great! Refer to bug 338978!

Things I've heard so far

1. Give direct access to profiling data - right now you can save it as html or text, but you can't view it directly (or so I was told, haven't verified this). If you're debugging and don't want to let go of the browser which is stopped, then that's a problem because you need that browser to view your profile output. Which is kinda odd and confusing and not really a Nice Thing. (talking to Hish)
2. Anonymous functions get lumped together when profiling. Baaaad. On the other hand, you can just rename the functions yourself...
3. Getters/setters? [Bug on file. Might want that fixed. Though since IE doesn't support them in 'our' way, it's not too high-priority for webcontent]
4. JS 1.7?
5. Asking an Opera evang. guy what he would want from a JS Debugger (they don't have any):

• • Be given access to the values of (any/all) variables at runtime
  • Set breakpoints and step through code.
  • I don't think he thought of anything else... :-)

1. Be able to debug from the "Slow script" warning thing, because you want to be able to see what's going on if your script is unexpectedly looping insanely or something like that. (Hish or Daniel or... I don't remember who came up with this)
2. Give access to the DOM Inspector if you have a variable which is referencing an element in the page.
3. Provide a real js console to evaluate expression and actually have an effect on the website, instead of the lousy "not so great" functionality of the current console.
4. Better XBL debugging. Daniel Glazman named a few weird bugs - need to check if they've been filed.

Things I've thought of so far

1. Simpler UI (than venkman/VS/Eclipse)
2. never debug chrome (pref is hidden).
3. findable line/file/tab origin in the backend so the frontend can be specific to the code that the user cares about.
4. evaluating js in the context of other windows (iframes within page, other tabs, other windows, etc.)

Things I don't like about Venkman

1. It disables the window you're debugging. Can't navigate or use other tabs to do anything useful.
2. It uses a different window, meaning you're somewhat 'detached' from the thing you're debugging (as a webdev).
3. It's S.L.O.W. I have no idea why, but for example, on my admittedly quite dated laptop, it took me 15 seconds to start it up when trying to debug a simple webpage thing when at XTech. 11 of those were spent firing up JSD. Regardless, it would almost have been faster for me to just insert an alert() in my code, reupload and reload. 'almost' since the WiFi was really slow.
4. There are lots of panes with bulky non-smooth UI. This makes the debugger look needlessly complicated, and also slow because of all the magic the floating views need.

Things I don't like about Firebug 0.4

1. It doesn't disable the window you're debugging (it's probably impossible to do that properly, but it seems like this is a Bad Thing). It does seem to disable the scripts in some way, which means it's not /that/ easy to make it screw up.
2. I can't get a list of breakpoints.
3. I need to switch to a different firebug tab to evaluate js / change a variable's value.
4. The stack is done in a dropdown box. While this saves debugger real-estate, it's not as easy to keep track of the stack while you step through your code.
5. I can't set watches.
6. The variable/value tree is done in HTML, which has the advantage of making it look neat, and the disadvantage of being prone to breakage when you resize elements inside firebug or when the value of some variable becomes too large. Specifically, names of variables get thrown onto another line than the > tree thing.
7. The variable/value tree doesn't seem to indicate newlines inside the values in any way.
8. Switching firebug tabs to/from the debugger is horrifically slow. At the moment I don't know what it's doing, but it seems bad.
9. If you open two pages with the same script running, set a breakpoint in one tab, break in that, switch to the other tab, open firebug, it will have the breakpoint, but it won't break on it. This is weird.
10. It seems to remember breakpoints, but if you close a tab which used to have a breakpoint in it, go to the same page again, it'll break on load, for some reason, but not show the stopped script and just sit their waiting for you. Hitting the 'run' button will then make it load the rest of the page, after which it stopped again, but this time the 'run/break' button was still on 'break' (hitting it twice, again, gives you back normal behaviour). This is weird.
11. I crashed it on gmail, and hung it on it when trying to reproduce. TB19037069H, TB19039966X
12. The run/break UI is kinda broken on about:blank. Firebug doesn't seem to like about:blank in general, I've seen it freak out on that in weird ways before (as in, spawn limitless amounts of error messages into the console). Can't seem to reproduce that anymore (yay!).
13. The 'disable firebug' pref is royally broken. The debugger and everything else doesn't seem to care about it anymore.
14. Where's my pretty-print?

Possible solutions for some of the problems listed above

1. Integrate watches and variable listings in one pane. This still offers the same functionality, while removing complexity and saving screen real-estate. Possibly have an option not to show variables by default, so you can use watches only, making a script with lots of variables easier to debug in a more focused way.
2. Put the scripts and windows lists inside a sidebar-like pane that you can pop in and out, saving lots of real-estate - after all you tend to not need these while debugging. It should be easier to remove/add them whenever you want.
3. Try if you can disable the window within the tab and not everything else... not quite sure whether you can, or maybe could with some JS backend fixes...

Profiling

Profiling