console.log() statements. Some times we just want to know: what code runs when I do this? A simple way to summarize the execution path would be automatically inserted
console.log() calls on every function call or every call matching a pattern and so on.
CSS by Example: If you know CSS, Firebug let’s you into tweek a page to perfection. But what about the rest of us? Every time I mess with CSS I have to spend most of the time reading docs or looking up examples. I’d like a “for example” mode that shows me just a bunch of different thing CSS can do to an element.
CSS Connectors: Actually I don’t know how to name this or exactly what I want. I do know that want fluid layout but I don’t want to read forty different ways to do three column layout again. Maybe we can extend the Firebug inspector to show the box hierarchy and/or the boxes that the selected box is directly related to.
Live Object Sites: By a large margin the most requested feature for Firebug is Issue 179, Create a unified patch from CSS changes. As you can see in that issue there are two Firebug extensions that solve this for some cases. Our work on 1.6 should make those extensions easier to install and update. But this is just the start: we want every kind of edit to be synchronized. Maybe should also explore more aggressive approaches like Dan Ingalls’ Lively Kernel.
Memory Analysis: As Web applications grow and grow we are increasingly running into memory limitations. Analyzing memory usage is hard; I think we need several different approaches. We are looking at trying to use a Memory analyzer created by Dion Almer and Atul Varma and their colleagues. It gives you the number and sizes of objects. We’ve also discussed a “high memory” analyzer, part of a JS function profiler that would just tell you which functions bumped up the high-water mark, a very fast way to pinpoint a serious problem. Another critical tool would find back links for a given live object: why isn’t this one being garbage collected?
Widget-set Debugging: Many Web pages these days are built on toolkits like Dojo, ExtJS, jQuery, or Scriptaculous. Users at the toolkit level think in terms of widgets and events of the toolkit, so debugging at the HTML and DOM event level is tedious and confusing. Firebug should have direct support for toolkit debugging.
Code Coverage: Lots of folks use test-driven development or at least have some test suite for their code. We need some easy to use ways of finding out what parts of the code are not being touched by our test suites. We also need to know what HTML and CSS does not actually contribute to the page even if it is shipped to users.
Integrated Debugger Environment: Firebug should support multiple simultaneous views of more than one panel and have better integration support with editors and Web servers.
FireCrystal and WhyLine: Stephen Oney in Prof. Brad Myers’ group at CMU has a very cool prototype for a graphical tracing tool called FireCrystal; it animates a time line with snap shots of the Web page so you can find out when a particular UI change happened or study the graphical update in slo-mo. A former student of Prof. Myers, Andy Ko, now a Professor at U Wash., created a Java debugger for graphical applications that supports query-style debugging. I’d love to explore the potential for these ideas in Firebug.
Finally, I am collaborating with Salman Mirghasemi and Prof. Claude Petitpierre from Ecole Polytechnique Fédérale de Lausanne, on Salman’s new approach to conditional breakpoints (well that hardly does the justice to the idea) and we hope to bring some of these ideas into Firebug.