>Console ideas

>I recently filed bugs 635504 and 635502 in order to make Firefox’s Web Console customizable via the new Addon SDK and to create a global ‘Browser Console’ that lets you peek at all of the activity going on under the hood in Firefox.

The interesting exercise will be cannibalizing the Web Console to create a global console that displays all errors, css parse warnings, network activity and other events. The filtering interface will need even more options to cut through the density of messages. The cool part will be making commands – and perhaps APIs – that give you access to all of the services, observers, browser tabs and other Gecko bits currently running.

Live inspection of these objects will be a powerful tool for those interested in hacking on Firefox, but don’t know how to start.

The first customization of the Web Console we are planning is integration with Rob Campbell’s ‘Workspace’. I would like to see a console and workspace either side-by-side or be able to toggle between them, with the current console automatically providing a logging API.

I find the Workspace is already an essential tool when I start hacking something together – especially in the  ‘chrome’ context. The Workspace can save your snippets to files, so any commonly used tools and functions can be used as templates.

If you think of anything that would automate or make easier repeated tasks or techniques you use when hacking web apps or Firefox, let me know.

>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.

Read more about this beta release on the Official Mozilla Blog
http://blog.mozilla.com/blog/2010/07/06/firefox-4-beta-1-tell-us-what-you-think/

>The toast has landed butter-side up

>Today, the web console code attached to bug 534398 landed on mozilla-central. This means that starting with tomorrow’s  nightly, you will have a new “Heads Up Display” console to tinker with:

If you are interested, the Meta bug is here

There are a number of followup bugs that need to be addressed, the list is here:

Console Bugs

There is a lot of work to do yet, including some platform work. Two glaring bugs are:

“When reporting errors, warnings, etc… to the consoleService, report the originating window or context “

The existing errorConsole in Firefox has messages sent to it that do not know what tab the error originated in. We really want to isolate all messages you see to the tab you care about as a web developer. It becomes tedious to try and watch the scrolling messages at times if a “noisy” page is loaded in one of your 200 open tabs. So you will notice that not all errors are displayed in the console.

and

“create event or method to determine the source contentWindow of loading images and media”

In Firefox, images are loaded differently than script, css and html pages, so much so, that it is difficult to trace these image loads back to the originating tab as well.

Once these two bugs are fixed, your console messages will be very accurately focused to the tab you care about.

The console itself has the standard API: console.log, console.info, console.warn and console.error.

This initial landing into Minefield nightly will hopefully generate some valuable feedback from web developers and Mozilla developers alike. Please do not hesitate to comment here or even better in bugzilla.

Cheers,

David

>DevTools – Console update May 28

>Console patch is up for review on bug 534398

Have a few issues trying to get image loads to log to the correct console. bz is helping me figure out these crazy HTTP load issues.

Filed a bunch of followup bugs: http://tinyurl.com/3af65f2

EDIT: try build is here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/ddahl@mozilla.com-535790457eaa/

wow – the try server does debug builds now, cool.

Spent some time talking with jimb and sayre about how the console and debugger will fit together and what kind of user experience we are thinking about for the debugger, which has to be GREAT.

Signed up robcee and myself to do a science fair exhibit on DevTools at the Summit.

Next:

I plan on utilizing my charcoal grilling apparatus at some point this weekend.

>DevTools Console update for May 21

>Much more work on bug 534398 – Found some issues with correlating network traffic with correct HeadsUpDisplay, mostly network traffic where the request is an ImgRequest. I have been getting advice from bz and dougt. This means that the console does not log any network traffic where an image or favicon is loaded.
Also, have an issue where nsIConsoleMessages cannot be correlated with the correct (or any) HeadsUpDisplay. This will need some Platform work, see bug 567165
I have most of the filtering working, there are some bugs with the “binary” on/off filters and I am almost there with the string filter. I should have those sewn up on Monday, and a patch for review by Tuesday midday.

Next:

Nail down filtering, ask for review, (any takers?), fix all tests and write a few new ones.
New try build and a blog post.

Coordination:

Platform attention on bug 567165. It would be great to be able to get the “contentWindow ID” in each content JS and CSS consoleMessage. That would make message isolation (to a tab) “easy”.

>DevTools Console Status 4-23-2010

>”Heads Up Display” bug 529086 Added properties file and stringBundles to source files that do UI stuff. All strings are L10N ready, adding more will be trivial.

Met with FX UI team to begin brainstorming about the Console UI, good ideas came out of this meeting, one of which is using an “arrow panel” when first activating the Heads Up Display. Filed bugs 559481 and 559482

Looks like I have coerced mrbkap for a first-round review – “next week”.

Began implementing the “filtering mechanism” and UI (just a toolbar for now as per Limi’s advice)
Next:

Will spend some time Monday updating the wikipage and milestones with time estimates and what a first-landing looks like.

More filtering work as this is going to be tricky to turn certain behaviors on and off. I continue to do clean up and make sure code is adhering to the style guide.
Coordination:

Would love some feedback on bug 561458 about how the UI is initiated and applied to the browser. Overlays are pretty much out – I think.

I will create a new try build as soon as the filtering is working properly.

>DevTools Console Update for April 2

>Still plugging away on bug 534398 “Heads Up Display – console”:

Implemented DOM Mutation logging as well as more concise network logging.

Removed all programmatic CSS and started using the css service.

Tweaked the UI to make it more “usable” while under such heavy development.

Implemented a ConsoleStorage module to keep all logging data, as well as make it easily iterable. This is mainly for the “global console”

More work on “JSTerm” or “Javascript Workspaces”

Screenshots:

Console: http://yfrog.com/bescreenshot012qp

JSTerm: http://yfrog.com/74screenshot013xp

Everything is up to date in the repo: http://hg.mozilla.org/users/ddahl_mozilla.com/heads-up-display/

Next:

Need to make each logged message “updatable” by asynchronous but related log messages.

Also need to add an exception listener that can log to the corresponding tab’s “Display”.
Should be straight forward.

Add preferences for turning on and off functionality, etc.

Slowly breaking things out into smaller, stand-alone and tested modules or additional services (maybe) – to make review easier.

Coordination:

Need to get feedback and start reviews on the various bits: HUDService, HeadsUpDisplay module, storage module, JSTerm module.

Update: Latest Try Builds are here: https://build.mozilla.org/tryserver-builds/ddahl@mozilla.com-HUDConsole0402/

>DevTools Console Status

>”Heads Up Display” status:

Console work (bug 534398): Removed all /browser/ aspects of this patch. Asked Vlad for first-pass review.

I am sure it still needs some “distilling”, etc.

Filed more bugs to block the tracking bug 529086
Created a JS sandbox/interpreter interface. This seems to be an EARLY mock up of “JS Workspaces” as Mr. robcee likes to call them.

Actually got some key bindings working on the input textbox: ctrl-a, ctrl-e, and to some extent “history” (up arrow, down arrow)

All code is checked into user repo: http://hg.mozilla.org/users/ddahl_mozilla.com/heads-up-display/

Began working on implementation of HTTP traffic observation and understanding of how “Load Groups” work. (thanks Mossop)
Latest screen grab is here, again this is with zero thinking/commiseration about UI (with UX team), etc…: http://yfrog.com/78screenshot009jwp

Try build is cooking this evening, will update when it is finished. Here they are: https://build.mozilla.org/tryserver-builds/ddahl@mozilla.com-HUDConsole_ddahl/

We grilled Fajitas on Thursday at work, OH YEAH!

Next:

Answer first pass review with code and comments, keep on working on HTTP observation, console JS evaluation.

>Devtools Status Update 2010-03-12

> The current console patches are found on bug 545266 and bug 546708 – also try builds will start once things are actually usable – I hope end of next week. It turns out that trying to attach (and keep attached) an arbitrary object on a nsIDOMWindow is a it of a pain – from outside the window’s constructor. sicking told me about his patch for detecting new windows (before content scripts run) and attaching objects to them: bug 549539 – which landed late today. Yay. With this patch on trunk it should be trivial now to detect window construction and attach a console.

Next:

Work with the new window detection hooks to implement the observer that keeps window consoles re-appearing. Every load of the browser creates a new nsIDOMWindow – news to me, anyway.

Coordination:

I may need some initial “WIP CSS” help to pretty up the logging output. I’ll try my hand at it next week after I have gotten the initial event handling worked out.