*Free after bug 127582, comment 0
Proposed mentors: Robert Ginda and Mike Shaver
The aim of this project is to provide a simple, localizable and to-the-point interface for webdevelopers to inspect, debug and profile their code. By which means is not yet clear: extending or slimming down Venkman and/or other tools, or creating a new one are roads that could be taken to solve this problem, depending on user feedback.
The complexity and overhead of using a debugger isnít unique to Venkman; nearly every IDE includes some sort of debugger, but these are often ignored by developers due to the amount of effort that must be expended to actually use the debugger and step through their code.
Moreover, webdevelopers often need the help of other tools, such as the DOM Inspector, Firebug, or a logging framework to actually figure out what's going on (assuming, of course, they don't use alert() anymore). These tools are not well-integrated, nor complete, nor are they particularly focused on the problems people in the real world face - they're focused on separate issues that may eventually lead people to solve their problem, but don't always address the actual problem(s) directly.
Plan and Rough Timeline
Two personal things have been taken into account when writing the plan below:
- My university semester does not end until July 2nd.
- I am on vacation from July 9th until July 16th
Stage 1: Define usecases
Stage 2: Define concrete requirements to address the usecases
At this point it is possible to see what the debugger should be able to do, what it doesn't need to be able to do, and what the UI requirements for it would be. This is also when it would become apparent if going from Venkman (or even Firebug) is a good idea, or if something should be built from scratch. Regardless of what is decided, it would probably depend on the jsd libaries, and it could of course always borrow existing Venkman, DOM inspector or other code that is deemed useful. Since the debugger would need jsd, it is also quite possible that work on jsd would need to be done to provide a more stable or functional experience. Examples of such work are the problems defined in bug 228205 and bug 229824. The concrete requirements should all be done after 3 weeks, so before June 12th.
Stage 3: Implement the requirements
This is it, really. The exact requirements have been formulated by now, and this is where all of it should be implemented. The goal is to get these into the Mozilla codebase, either as code for Venkman or as an alternative debugger. For this, review by the mentors shall be necessary, so last-minute work will be hard, if not impossible.
A Firefox extension that:
- works on the 1.8 branch releases, and preferably also on trunk.
- allows webdevelopers to debug and inspect their code, and possibly lets them profile it.
- is fully localizable.
- is free of (strict) js warnings and errors.
- meets the requirements outlined during the project in stage 2.
Short Bio and Motivation
I do not have much experience with C/C++ code in the Mozilla codebase or in general. I am, however, very motivated to learn how the underlying framework for the technology I use works. Additionally I simply want a better experience for Mozilla- and web-developers who want to debug their code. These are my main reasons for applying to work on this specific proposal.