>Web Developer "Console" in Firefox 4.0 Beta 1

>Firefox 4.0 Beta 1 includes some new web developer tools, “Console” and “Inspector”.

This post will cover the Console, what it does now and the direction we are headed with it. The developer tools team would like feedback from web developers and others who might use these tools, so please try it out and either comment in Bugzilla, through one of our feedback tools (such as http://www.mozilla.com/firefox/beta/feedback ) or in the comments of this blog.

The Meta Bug for this Console work has a list of blocking bugs, for those who are interested.

***

What is the “Console”?

The console displays log messages, warnings and errors that originate in web pages. The current Error Console in Firefox displays messages that originate in any open web page, Firefox itself and the underlying Gecko platform code. One of the main changes we wanted to make with the new Console was to pre-filter all of the messages so you are only seeing messages that originate in the current browser tab. You can activate the Console though Tools menu -> Heads Up Display. (The “Heads Up Display” name will be changing soon to something like “Console”).

The existing Error Console is displayed in it’s own window, the new Console is initiated per browser tab, and is displayed (by default) as a panel that drops down over the corresponding tab’s web page. You can open the console for each tab if you want to. Each will funnel console messages about that document to the correct console.

The existing Error Console:

The new Console:

Now that we are tying the log messages directly to each tab, there is a lot higher signal to noise. This is, of course, a work in progress. There are a couple of bugs that need to be fixed before all of the messages are properly identified as being from a particular tab: bug 568034 and bug 567165.

Another goal is a rich, interactive (command line) interface that allows quick introspection of JS Objects you might be interested in. You can execute functions, write code directly into the console command line and the output displays the result of the executed commands. We want the command line to be a very powerful tool for users to quickly find out the state of variables and the effects of function execution.There are several bugs on tab-completion, JS object inspection and helper functions, which are under heavy development right now and should be available in upcoming betas.

Tab completion in the command line interface will allow you to easily introspect the properties of various JS and DOM objects.

Helper functions in the command line will allow developers to have a “$” function regardless of whether a “$” function is already defined. If defined, nothing happens and the developer can use her existing function. If not, we provide a “$” that does document.querySelectAll, among other things.

The console work is just getting started. The recent addition of some additional engineers means we will be iterating quickly, so please check it out and give feedback often. You may want to use a nightly build for bleeding edge features. I will post additional “branch” builds to this blog as they are available.

>IMHO this is duplication of effort.please consider joining the firebug team, and streamlining the UI so that it is suitable for inclusion in firefox by default.or maybe develop "Firebug Lite" based on the common codebase (the firebug team is already working on a suitable code split to enable something similar, right AT THIS MOMENT).

>@Scott Tsai As we develop the console and inspector we are trying to improve and create APIs that Firebug can take advantage of as well. Think of Firebug as the heavy duty power tool, and the built-tools as the future of "View Source". As far as interaction with Firebug, we do plan on writing some APIs that allow Addon developers to extend these tools. This is still germinating, of course.@Mike Kaply – We plan on making things configurable.@Anonymous – We need developer tools that are baked-in. Taking an add-on as complex and sophisticated as Firebug and landing it into the Firefox code base is not easy. The feature set we are looking at having in Firefox is more narrow than Firebug's as well.

>Why are baked in developer tools needed exactly? Most of the worlds web browsing population aren't web developers and won't ever need to see the DOM or console messages. I'd even go as far as to argue that 'view source' and the basic error console aren't required features for most people.For developers there's Firebug and developers are the type of people that will already know about Firebug or be able to easily find out about it.Personally I'd say yes, put in the APIs that Firebug and other extensions can take advantage of, but don't bother re-inventing the wheel when it comes to what Firebug already does and does extremely well.

>I really like the new Heads Up Display for debugging. What's the component for the Heads Up Display in Bugzilla? I'd like to report the fact that the "Filter" field doesn't work in the display.Thanks,Manoj

>On one hand, I don't think it would be in Mozilla's best interest to delegate all of their web developer tools to the Firebug team. It might be a duplication of effort but at least Firefox will have a baseline feature set for web devs – especially if they are the same tools used by the moz team.

>If firefox's console does not have the features of firebug, there is no point in having it at all.Everyone is use to firebug, its UI and feature. At first it the console looked promising but it I would still use firebug in a heart beat.Couldn't there be better things to work on then a console as again, your previous error console was fine as it was hardly used (ie. casual user might use it) but firebug dominants web development on firefox.It was fine the way it was. Maybe you guys should work on hardware acceleration in firefox like IE9. I hate to say this but if firefox doesn't pick up on this stuff now, it could be the end of a great browser.

>@Fire UserIt seems like you are averse to change, and that is too bad. The console that landed in Beta 1 is just the beginning and has about 20% of the features it will have. (You have to start somewhere).I guess you have never been bitten by FireBug when it is incompatible with the latest version Firefox. Please understand, these efforts will actually improve Firebug as well.

It shouldn’t need to. But I’d like to clarify what happens with Firebug, since it has changed with Firefox 4. Enabling Firebug disables one of the two JIT engines (the tracing JIT, or Tracemonkey), but the other JIT (the method JIT, née Jägermonkey) is only slightly slowed down. And if you’re either debugging or paying attention to the console, the method JIT is much more relevant. The tracing JIT only really wins now for specialized, computationally intense code; even when it’s faster than the method JIT, the difference is unlikely to be noticeable. This is very different from before, when disabling the one and only JIT (the tracing JIT) threw you into the interpreter, which *is* a very noticeable difference. (And yes, disabling the debugger will switch you back to the fully fast path.)

>To avoid these repetitive negative firebug related comments you should write a post clearly stating how this new inspector relates to empowering firebug (and other tools) in the future and helping firebug not be incompatible with future firefox releases.Then link to that article at the beginning of every future post on this subject.I took the time to look for a post on WHY there was this apparent duplication of effort and came up empty. Luckily I read your other responses in the comments and it started to make sense.

>@Corban Brook we will not need to disable JIT afaik at this time:)@Anonymous People should look at this issue like this: of the 400 million users of Firefox only 5 or 6% of them have Firebug installed. There will be times when tools like this (although not as powerful as Firebug) will become useful to you inspecting things on a friend's/mom's/etc computer. Just like "view source", these tools will help people understand what is happening on a page and in the browser. That alone is enough reason to build these tools.Cheers,David