User:GijsKruitbosch/JS Debugging/Tasks

< User:GijsKruitbosch‎ | JS Debugging
Revision as of 14:20, 16 June 2006 by GijsKruitbosch (talk | contribs) (Fixing shaver's nits, fixing my own commentary, fixing backend-needed listings)

Importance-ordered Task List

A small note about this list: importance != working order, given that some of these items need other items, and that some require back-end changes which will need to happen fast, if at all, on the 1.8.1 branch (which is what I'm trying to cater to).

Front end work is being done on: Firebug

N Task Needs backend changes Bug number Result
1 Implement list of Breakpoints No - None yet
2 Implement Watches No - None yet
3 Make the originated document accessible from any error in the console No? bug 228205 None yet
4 Frontend adapted to keep breakpoints and such separate on a per-document basis (for Firebug's console) (see above) No? bug 228205 None yet
5 Be able to go from a var referencing a DOM element to that DOM element in DOMI No? - None yet
6 Be able to debug from the slow script warning dialog. Yes? - None yet
7 Newlines are lost in the watches view. No - None yet
8 Changing variable values / evaluating js shouldn't require changing tabs away from the debugger (in Firebug) No - None yet
9 Evaluate js in different windows/tabs/iframes No - None yet
10 Provide immediate access to profiling data No - None yet
11 Anonymous functions should not be lumped together in profiling. Presumably not - None yet
12 Double-check handling of about:blank and (related) running/stopped state tracking in Firebug. No - None yet
13 Figure out why I'm crashing on GMail with firebug enabled (hack/sneak/workaround?) Hopefully not. - None yet
14 Fix wrapping of variable/value tree No - None yet
15 JS 1.7 improvements Yes? - None yet
16 Debug mutation events (watch DOM elements) Yes - None yet
17 Getters / Setters improvements Yes? - None yet
18 'real' stack list (not a dropdown) No - None yet
19 Inline editing of functions etc. No, hopefully. - None yet
20 Pretty print No - None yet

Getting to the document that error X originated from

Shaver should write this sometime (see below)

Discussion

I would probably order these things higher:

  • immediate profiling
  • newlines in watches view (but there's no watch support yet, so?)
  • eval JS in tab/frame/etc.

And these things lower:

  • JS 1.7
  • inline function editing

But I think you're generally on the right track. I need to write here how we can track what document an error came from without biting off everything that's in the current bug 228205, too. Basically involves finding the current document (via cx->contextPrivate->scriptOwner->frameElement or some such) from the handler called for exceptions and errors, and keeping track of it. We could also "just" have the console error object QI to nsIException, but I bet that would make some people API-sad, so I'm interested in us keeping the hacks to our side of the line if we can.

-- shaver

Done, I think. GijsKruitbosch 07:20, 16 June 2006 (PDT)