Confirmed users
293
edits
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
== Things I've heard so far == | == Things I've heard so far == | ||
# 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) | |||
# Anonymous functions get lumped together when profiling. Baaaad. On the other hand, you can just rename the functions yourself... | |||
# 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] | |||
# JS 1.7? | |||
# 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 | ** Be given access to the values of (any/all) variables at runtime | ||
** Set breakpoints and step through code. | ** Set breakpoints and step through code. | ||
** I don't think he thought of anything else... :-) | ** I don't think he thought of anything else... :-) | ||
# 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) | |||
# Give access to the DOM Inspector if you have a variable which is referencing an element in the page. | |||
# Provide a real js console to evaluate expression and actually have an effect on the website, instead of the <del>lousy</del> "not so great" functionality of the current console. | |||
# 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 == | == Things I've thought of so far == | ||
# Simpler UI (than venkman/VS/Eclipse) | |||
# never debug chrome (pref is hidden). | |||
# findable line/file/tab origin in the backend so the frontend can be specific to the code that the user cares about. | |||
# evaluating js in the context of other windows (iframes within page, other tabs, other windows, etc.) | |||
== Things I don't like about Venkman == | == Things I don't like about Venkman == | ||
# It disables the window you're debugging. Can't navigate or use other tabs to do anything useful. | |||
# It uses a different window, meaning you're somewhat 'detached' from the thing you're debugging (as a webdev). | |||
# 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. | |||
# 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 == | == Things I don't like about Firebug 0.4 == | ||