User:GijsKruitbosch/JS Debugging

Got comments? Great! Refer to bug 338978!

Note: The numbers here are irrelevant, it would have been an unordered list except that numbers make things so much easier to refer to when triaging something.

Index

JS Debugging

Profiling JSD

Task list

Associating a document object with an exception/error message in the console

Firebug "Bugs"

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. 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)
6. Give access to the DOM Inspector if you have a variable which is referencing an element in the page.
7. 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.
8. 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...

__toplevel__ and disappearing scripts

[this is only how I, Silver/James Ross, understand things]

SpiderMonkey (and Mozilla's use of it) wont keep scripts around forever, of course, but some script objects die very quickly. One of these is refered to in Venkman as __toplevel__, and is the script object for the global scope in a webpage (for example).

AIUI, it gets created first, when the <script> is seen/handled, and SpiderMonkey runs through it running the code and defining the functions. Once that's completed, it tends to go away. I don't know any details, this is just based on something someone (possibly Robert Ginda) said, or a comment in Venkman's code.

The issue is that once the SpiderMonkey script object has evaporated, you can't get any information from it (duh), which means you can't calculate what lines you could set breakpoints on (they'd have to be future breakpoints).

Don't all breakpoints on top-level code in an already-loaded page have to be future breakpoints? Or does Venkman give a way of re-running that top-level code without reloading the page? -- shaver

Yes, they do have to be future breakpoints, but Venkman uses the isLineExecutable/line map stuff to determine which lines can be set as future breakpoints. (The source code view in particular only numbers executable lines, too.)

Ah, yes, OK. So would it be enough to do minimal work to protect the script object against GC, and unprotect it when we would normally discard the line map information? That would give us a material performance gain, I believe, and avoid the disappearing-script problem you rightly fear. --shaver

I'm not too sure when such protection would be turned off, as the line map for a given script may be needed at any point up to the disappearance of it from the loaded scripts list (which I believe occurs when all the JSScript objects for that instance evaporate). More investigation on the result of the profile is needed, as I can only find calls to the isLineExecutable/line map stuff for __toplevel__ and not for functions unless the script's URL has breakpoints set.