Next steps for Mozilla Developer Tools

Standard

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.

We want Firefox to have the best developer tools of any web browser, and we want to push dev tools for the open web in new directions. You can help through ideas, code, tutorials, etc. Join us on the dev-apps-firefox mailing list/newsgroup, join the Firebug project or email me directly if you want to help.

And, in case you’ve read this far, here’s a link again to the current snapshot of our planning.

Introducing the Web Console

Standard

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.

The Web Console atop a popular website

You can see the Web Console for yourself today by downloading the Firefox 4 beta.

The Log

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.

If you open the Web Console and then go to a page, you’ll see a whole bunch of output. Typically, there will be many “Network” requests listed. Sometimes, you’ll see CSS or JavaScript errors displayed. It doesn’t take long for that output to quickly become overwhelming, so we’ve got a simple solution in place to deal with that: filtering. Just above the log output area, there are a number of controls that you can use to pare down the output and see just what you need to see.

  • The Net, CSS and JS controls determine which of those types of messages from the browser should appear in the output.
  • The Errors, Warnings, Info and Log controls determine which JavaScript-generated messages should appear in the output window (see “The console Object” below
  • 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.

Network Details

The “Network” requests that appear in the log output show you the URL to which the request was made. But what do you do if your JavaScript made a request to the right URL, but the data that came back isn’t what you expected? If you click on a network log entry in the next beta of Firefox 4, you’ll get a panel with a bunch of details about the request:

The network request details panel.

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

If you’ve used the excellent Firebug extension (more on Firebug below), you’ve quite possibly encountered its “console” object that is available to JavaScript. console provides a number of useful methods, including a set used for logging information: log, info, warn, error. All four methods work the same way and represent different levels of information logged from log as the lowest level to error as the highest. You can pass in multiple arguments and they will have their string representations glued together for the output. For example, if the variable food is “avocado”, then console.log(“My favorite food is”, food, “and its info is”, anObject) will output “My favorite food is avocado and its info is [object 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.

The JavaScript REPL

Read Eval Print Loops are fantastic for figuring out how a language or environment works and for testing things quickly. The Web Console features a REPL for JavaScript that gives you access to everything on your page. For every expression you type in, the Web Console will automatically output the result of that expression. That means you can use it as a simple calculator:

6*7=42, but you knew that

For your convenience, the Web Console will automatically try to fill in variable and function names that it knows about:

Automatic completion

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:

Here we see that jQuery is on the Reddit home 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:

Reddit with the header hidden

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:

The object inspector looking at a jQuery node list

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.

Firebug

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.