getfirebug.com has Chromebug 1.7a1, a release of the debugger we use on Firebug. Firebug 1.7a1 should be installed first. For more information on using Chromebug see the Chromebug User Guide.

jjb

getfirebug.com has Chromebug 1.6a10, the Firefox extension debugger we use for Firebug.

• Breakpoints saved between runs
• Filter simplified and only applies to Files list now
• Back/Forward navigation as in Firebug 1.6a10
• Extensions panel added
• When you stop on a breakpoint all nsIDOMWindows have event suppression.
• Panels, contexts remember their last settings between sessions.

Please note

• Use Firebug 1.6a10 with Chromebug 1.6a10
• Don’t install jetpack prototype or SDK with Chromebug.

jjb

Please post comments on the newsgroup.

getfirebug.com has Chromebug 1.6a7 and Firebug 1.6a7.

Yes, I know we just had Firebug 1.6a6. But Chromebug had one problem left to fix: the context did not restore correctly after restarting. After working all afternoon I tracked it down to a line in Firebug.

Plus the Firebug command line in 1.6a6 was broken if you used NoScript. What? NoScript and Firebug? Hey it happens.

This version of Chromebug has a big clean up in the code. Some highlights:

• Sandbox context have better names,
• Sandbox contexts use evalInSandBox for their command line,
• New panel XPCOM for non-window contexts (eg BackstagePass)
• New panel Overlays for window contexts (eg browser.xul).

I’ll do a post with screen shots on these soon.

jjb

Follow up in the newsgroup please.

getfirebug.com has Chromebug 1.6a5. As usual, this release should be used (only) with a matching Firebug version, 1.6a5.

• All contexts in the stack are marked as ‘stopped’ when you hit a breakpoint. This means if your stack crosses from say a window to a component, then the debug controls remain available and the stack shows across the top. Like it should .
• The “all files” menu now syncs to the context’s script file menu to make it a little less confusing.
• Remove the use of FUEL which is not supported by Fennec or other XUL applicationss
• Many smaller bugs as always.

jjb

Followup on the newsgroup please.

Later this evening getfirebug.com will have Chromebug 1.6a4.

• Attempt to delete Chromebug contexts when windows are destroyed. Seems to be working.
• Different approach to XUL / XBL files, now can debug XBL JS
• Only change the context by user control (not when windows open)
• Better naming of Sandbox and about:blank contexts
• Hacks to deal with jetpack hacks
• consolidate code to map stack frames to contexts
• avoid the gray blank area at the bottom of Firefox when inspecting.

Overall I’m more confident of this version that any in a while.

Also available is Firebug 1.6a4. About 10 tests fail, but I don’t know how to fix them. In these cases Firefox generates errors messages without file names, line numbers, or call stacks. I don’t know if we really have test failures or not.

jjb

Please followup on firebug newsgroup or the chromebug newsgroup

getfirebug.com has Chromebug 1.6a3. Please update to Firebug 1.6a3 at the same time.

This version add some support for “Sandbox” scopes used by jetpack. Lots of bug fixes so generally it’s starting to work better again.

Inspect is working well, but one problem I don’t know how to fix: Firefox 3.6 gets a blank area at the bottom of the page when you inspect.

jjb

Follow up in the newsgroup please.

I wanted to learn more about jetpack so (duh) I tried to debug a jetpack.  In case you’ve not heard,  jetpack is a Mozilla labs project to support easy, rapid development of Firefox addons using Javascript operating in an HTML rather than XUL world. You should try the tutorial, it really is easy and rapid!

Well, as long you don’t need to debug. Seems like the debug story is writing to Firebug’s Console.

Can we have a ‘jetbug’, a Firebug-like experience for jetpack? To start we’d need to understand what is jetpack. In part it is a Firefox extension: we should use Chromebug to investigate.

I ran the jetpack ‘boom’ tutorial from the about:jetpack URL. It is very short:

jetpack.statusBar.append({
 html: "Boom<i>!</i>"
 });

Then I inspected the “Boom” addition to the status bar:

In Chromebug we can see the implementation markup:

<statusbarpanel contextmenu="_child">
<menupopup></menupopup>
<iframe type="content" src="data:text/html,Boom%3Ci%3E!%3C/i%3E"
style="overflow: hidden; height: 16px; margin-top: 2px; margin-left: 4px; margin-right: 4px; width: 30px;">
</iframe>
</statusbarpanel>

So they put an iframe into the status bar to support HTML! Cool.

Next I want to find the Javascript above.  I did not get there yet, because Chromebug got confused by seeing a scope that was not a Window or BackstagePass. After some uh, logging based debugging of Chromebug, I can now see the Jetpack “Sandbox” object:

The console looks like an interface to Firebug. You can see the jetpack object used in the tutorial. Also in the sandbox is some jquery stuff and system functions.

Unfortunately there are ten other sandboxes whose role I don’t understand and I can’t find the source shown above. But it’s a start.  (Chromebug 1.6a3 will include what I’ve learned so far).

jjb

Followups on the newsgroup please.

getfirebug.com has Chromebug 1.5a4. Chromebug is the Firebug code adapted for XUL applications. It is the debugger that Firebug developers use to develop Firebug.  Note: you must install Firebug 1.5 as well as the Chromebug XPI. .

If you have looked any previous released version of Chromebug you will see a lot of changes. Some of these are inherited from Firebug.  Others are improvements in Chromebug itself.

The key features that we use routinely and that work well:

• Inspect over Firefox. Probably also works on Thunderbird.
• Viewing XUL and HTML, CSS styles, Layout and the DOM properties all work well.
• Javascript debugging.  Seems pretty good now, the only problem is when I breakpoint Firebug and then try to use the breakpoints in Firebug. Since they share the same core debug engine, the result is often that Chromebug fails to break.
• Error tracking in the Trace panel.
• The command line works for some commands at least (not something I use however)

It is also a fun tool for poking around under the covers:

• Try setting the context: to noWindow://BackstagePass and looking at the DOM panel
• The XUL Windows panel shows the output of the window mediator
• Filter: menu attempts to organize the chrome namespace (but I don’t use it after all)
• File: menu shows all the files Chromebug knows about (well just the JS files now).
• Tools > Open Chromebug Trace Console, if you want to know how to debug a debugger for debuggers

Problems areas:

• CSS editing is disabled because of Bug 503007
• No support for anonymous XBL nodes because of unimplemented functions.
• We don’t use Console or Net panel, so we don’t know if the work or not.
• Tools > Platform shows the components, but it is very slow then crashes Firefox.
• Some features under Tools have rotted but have not been removed.
• The source code looks like it was written by someone who did not understand XUL applications and did not have a lot of documentation for some of the APIs. (But its getting a lot better as the causes improve).

Finally Gerv helped set up a newsgroup, mozilla.addons.chromebug.   I welcome suggestions and comments there.

jjb

Followups to the newsgroup please.

If anyone is interested in a small but high impact project involving Firefox C++ code for Firebug, take a look at [Bug 503007] Provide Javascript Access to User Agent Style Sheets. It involves extending an existing interface, so most of the work is in understanding how to create a patch consistent with the Mozilla coding requirements and in creating the matching test cases to pass review.

The feature would allow Firebug and Chromebug to support User Agent Style sheets properly.

jjb

Since my first post on Chromebug 0.5a1 netted a nice offer from davida, it’s time for a sober look at the new UI. Here’s a reminder of the top part of the UI:

Let’s start at the top right, the “context” menu.  This is the main selector for the rest of the UI.  Each entry on this menu is a global scope, usually the thing Javascript developers think of as window.  Here is the top part of my context menu now:

Context Menu example for Chromebug 0.5a1 (top part)

At the top is browser.xul, the window for Firefox. Below that are four Firebug windows. Two are the browsers Firebug uses for its main panel and side panel. Firebug’s HTML templates (domplates) fill these windows. Two are the inner and outer window for Firebug’s tracing console.

Below that we have the Error Console window (I usually run with -jsconsole) and then the hiddenWindow. All of these are nsIDOMWindows.

Selecting any of these will cause the lower part of the Chromebug UI to fill with content from the corresponding  scope.  For example, selecting browser.xul will cause

• the HTML  panel to show the elements of browser.xul as rendered by Firefox;
• CSS will list the CSS files in browser.xul;
• Script panel will show the JS files loaded in to browser.xul;
• DOM will be document object for browser.xul.

(The Console and Net panels may show something, I don’t know yet).

Most of the time this will be great. The DOM panel should work well because its all about scope. HTML should be good if you understand how to work with windows in chrome code. Script may be more confusing.  Javascript can be compiled in to multiple scopes. For example, Firebug files are in both browser.xul and in traceConsole.html. Also Javascript in one scope can operate on content in another.  For example, Firebug has no scripts in either panel window, it just puts content in those windows. And finally, the total number of files in browser.xul can be large, leaving you drowning in stuff you aren’t interested in seeing.

Chromebug has some facility to help with these issues. Next time we’ll look into these, as well as ponder the contexts I cropped off the bottom of the menu. If you want to play in the mean time you can try Chromebug 0.5a1 (you also need Firebug 1.4a12).

jjb