I’m going to use this opportunity to make a couple of observations about Mozilla and planning. If you really just want to know about what we’re thinking of doing next in Mozilla’s developer tools group, you can take a look at the current draft of what we’ve got in mind for later this quarter. There are links in that document to join the dev-apps-firefox list or to email me. If you have feedback, let me know.
Now, for some thoughts on planning at Mozilla. I started working at Mozilla as part of Mozilla Labs. In Labs, we would often let an idea bake a little bit before turning it loose on the world. We wanted to have enough of an expression of the project available to show people what the truly idea is before they pass judgment on it. Open Web Apps was like that. A couple months back, an early take on some of that code was in a project called “vapour” on github. But, there are a lot of pieces involved in creating a coherent open web app ecosystem and getting a coherent picture together before starting the public conversation around it seems like a good approach to me.
Working on Firefox, however, is different. Firefox is an established project with a huge and active community. There have been a couple of times since I joined the Firefox team where I was discussing something with someone who then said “this discussion should really be in some public forum”. I think that’s fantastic. Firefox development is a public project from the first kernels of new ideas, as those ideas grow, when they ship and beyond. Firefox 4’s Panorama feature was like that. Ditto for Personas, which started out in Labs and eventually became a core, and very popular, part of Firefox.
Working on open source software is great, because it makes it possible for people to add to the project in so many ways. Collaborating with other projects both complementary and similar is much less formal (and risky!) than the kinds of partnerships that form between closed companies.
On the flip side, software projects get messy at times and, with Firefox and other Mozilla projects, that mess is out in the public to see. I’ve seen a handful of articles over the past few months written by people that didn’t really get this. Every company has dates that slip, features that are dropped, etc. With Mozilla projects, you get to see this happening as it happens. With closed software projects, you just see the final result.
I did some work with a company a few years back where one of their mottos was “plan is a verb”. Sure, plan is also a noun… but, in their world, planning is something that happens all the time and a plan is just a snapshot of the planning that’s going on. Any plans you see me post should definitely be viewed in that light.
David Dahl has been leading the work on Firefox 4’s Web Console feature and has blogged about the work along the way. Over the past month, we’ve landed a whole bunch of improvements to the Web Console in Firefox 4 Beta, and I wanted to give my take on what the Web Console has to offer for web developers.
What is the Web Console?
I first learned to program a computer in BASIC on a TRS-80 Model III. I’m dating myself there, but oh well. Believe it or not, my first programs didn’t always work the way I intended them to and, surprisingly enough, they still don’t. I had two main tools to help me figure out what was going on: a “read eval print loop” (REPL) and “print”. Using the REPL, I could type in simple statements and get immediate results, as a way of testing that how I think an individual operation should work is actually how it does work. Using “print”, I could have my program display certain values along the way so that I could make sure that they met my expectations while the program was running.
Even today, REPL and print continue to be two simple and fundamental tools for learning how a system works and troubleshooting problems. The Web Console gives you these two features for web pages that appear in Firefox.
You can see the Web Console for yourself today by downloading the Firefox 4 beta.
When you open the Web Console from Firefox’s Tools menu (or using the ctrl-shift-K/cmd-shift-K keyboard shortcut), you’ll see a panel drop down from the top of the content area of the browser. In the current Firefox 4 beta release, the panel is empty when it first opens, but the Firefox 4 final release will collect up logging messages even while the console is closed.
The Net, CSS and JS controls determine which of those types of messages from the browser should appear in the output.
Finally, there’s a search box to filter the output based on whatever you type there
Using these controls, you should be able to quickly zero in on the messages that will help you debug a problem with your page.
With the request and response headers and body and the cookies from the request, you can dive deep into the requests made from your web pages.
The console Object
By strategically using the different logging levels, you can make it easy to focus on just the messages that matter to you using the filter controls.
One more note: for Firefox 4, we’re playing it conservatively with the console object. If one is already defined on the page, we won’t override it. As of this writing, there is a bug that prevents the console from working properly on sites that define their own console object, but you can bet we’ll have that bug resolved soon.
For your convenience, the Web Console will automatically try to fill in variable and function names that it knows about:
By using the up and down arrow keys, you can also cycle through the history of commands that you’ve entered.
You can directly access variables that are on the page:
Note that variables that you define in the Web Console are not automatically exposed to the page. If you would like to change a variable on the page, you just need to put “window.” in front of the variable name. For example, if you enter the expression “window.foo = 1”, then the variable “foo” on the page will change to 1.
With access to jQuery and knowledge that Reddit has an element on the page with an id of “header”, it becomes a simple matter to remove the header from the page we’re looking at:
One more note about using the REPL: if your expression returns an object, the console will just show [object Object] currently. However, you can click on [object Object] and see the object inspector:
One nice feature of the object inspector is that it shows you a snapshot in time of the object. You can click the “Update” button if you want to see the current contents of the object.
The Firebug add-on has millions of users and has been making web development easier for years. If you’re one of those users, you’re probably wondering why the Web Console exists when Firebug already provides a console and much, much more. Back at the beginning of this post, I talked about how useful a REPL and print are in debugging, experimentation and learning. These things are so fundamental that we wanted them to exist in Firefox with no add-ons required.
Consider this case: you’re a web developer and you have a distant user of your application. They’re running into a problem with your app. They can tell you what’s on the screen, but they have no way of sharing a view of what the application has done to that point. If you have useful logging messages in your app, you can ask the user to copy the console output into an email message and send it to you, all without requiring them to install an add-on.
The Web Console is not a replacement for Firebug, but it will be a great tool to have in a pinch.
What’s Next for the Web Console?
We’re still in the middle of the Firefox 4 beta test cycle, so you can expect to see additional improvements and polish as the beta progresses and we head to the release of Firefox 4. If you’d like to get involved and help make the Firefox developer tools beyond awesome, talk to us! Discussion about the Firefox developer tools comes on the dev-apps-firefox mailing list/newsgroup and in realtime in the #devtools channel on irc.mozilla.org. I’m also happy to receive feedback by email.