Reintroducing the Firefox Developer Tools, part 1: the Web Console and the JavaScript Debugger

This is part one, out of 5, focusing on the built-in Developer Tools in Firefox, their features and where we are now with them. The intention is to show you all the possibilities available, the progress and what we are aiming for.

Firefox 4 saw the launch of the Web Console, the first of the new developer tools built into Firefox. Since then we’ve been adding more capabilities to the developer tools, which now perform a wide range of functions and can be used to debug and analyze web applications on desktop Firefox, Firefox OS, and Firefox for Android.

cola1

This is the first in a series of posts in which we’ll look at where the developer tools have got to since Firefox 4. We’ll present each tool in a short screencast, then wrap things up with a couple of screencasts illustrating specific workflow patterns that should help you get the most of the developer tools. These will include scenarios such as mobile development, and altering and debugging CSS based applications, etc.

In this first post we present the latest Web Console and JavaScript Debugger.

Web Console

The Web Console is primarily used to display information associated with the currently loaded web page. This includes HTML, CSS, JavaScript, and Security warnings and errors. In addition network requests are displayed and the console indicates whether they succeeded or failed. When warnings and errors are detected the Web Console also offers a link to the line of code which caused the problem. Often the Web Console is the first stop in debugging a Web Application that is not performing correctly.

webconsole

The Web Console also lets you execute JavaScript within the context of the page. This means you can inspect objects defined by the page, execute functions within the scope of the page, and access specific elements using CSS selectors. The following screencast presents an overview of the Web Console’s features.

Take a look at the MDN Web Console documentation for more information.

JavaScript Debugger

The JavaScript Debugger is used for debugging and refining JavaScript that your Web Application is currently using. The Debugger can be used to debug code running in Firefox OS and Firefox for Android, as well as Firefox Desktop. It’s a full-featured debugger providing watch expressions, scoped variables, breakpoints, conditional expressions, step-through, step-over and run to end functionality. In addition you can change the values of variables at run time while the debugger has paused your application.

debugger

The following screencast illustrates some of the features of the JavaScript Debugger.

For more information on the JavaScript Debugger, see the MDN Debugger documentation.

Learn More

These screencasts give a quick introduction to the main features of these tools. For the full details on all of the developer tools, check out the full MDN Tools documentation.

Coming Up

In the next post in this series we will be delving into the Style Editor and the Scratchpad. Please give us your feedback on what features you would like to see explained in more detail within the comments.

Jason Weathersby is a Technical Evangelist for Mozilla, evangelizing Firefox OS. He is also a committer on the BIRT project at the Eclipse Foundation, and has co-authored several books on BIRT integration. He is a proponent of HTML5, Open Source and all things related to web-based gaming.

@JasonWeathersby

57 comments

jamEs

I’m almost on board with the Firefox Dev tools, but I just can’t until you actually show margin and padding highlighting like Firebug. I find I use that feature all the time and it’s the first thing I notice missing when trying FF Dev tools.

September 24th, 2013 at 06:55
1. Robert Nyman [Editor]
  
  Thanks for your input! I assume you mean when elements are hovered in the Inspector tab – good to know!
  
  September 24th, 2013 at 07:06
  1. jamEs
    
    Yes, that’s exactly it. They show up yellow and purple. If you wanted to put one up on Firebug or Chrome tools add highlighting for positioning as well, so you can see when something has top, left, bottom or right attributes applied to an element visually.
    
    September 24th, 2013 at 07:09
    1. Andiio
      
      1+ for jamEs input
      
      September 24th, 2013 at 07:40
    2. Michael Beckwith
      
      While not perfectly what you are needing/requesting, there is the “box model” tab that shows a lot of this information. It just would be on click instead of on hovering. No luck at the moment, in Aurora, about positioning though
      
      September 24th, 2013 at 08:44
    3. Nick Fitzgerald
      
      We are working on it. Follow along at https://bugzilla.mozilla.org/show_bug.cgi?id=663778
      
      September 24th, 2013 at 09:22
Mindaugas

And on that note… css added by our add-on doesn’t register in the style editor as of FF 24. Firebug detects it no problem.

September 24th, 2013 at 10:09
1. Robert Nyman [Editor]
  
  Can you please file a bug on that, with more details and examples? Thanks!
  
  September 25th, 2013 at 00:30
  1. Mindaugas
    
    I don’t see the need for no examples here. I described the essence of the problem. I just hate bugzilla tracker and I can not dedicate my time for creating fake test add-ons, sorry.
    
    There’s nothing special about our add-on, it adds dom and css to a website. It is an old one (not made via SDK)
    
    CSS is loaded as USER_SHEET from a data-URL with nsIStyleSheetService.
    
    It uses a jar archive with unpack:true. Not that it should matter
    
    September 25th, 2013 at 10:26
    1. Jeff Griffiths
      
      I can confirm that the style editor doesn’t work using the SDK’s page-mod / contentStyleFile either. I’ll log a bug.
      
      September 25th, 2013 at 10:36
      1. Jeff Griffiths
        
        ….adn, the bug is here, if anyone wants to follow along add yourself to the cc list: https://bugzilla.mozilla.org/show_bug.cgi?id=920665
        
        September 25th, 2013 at 11:38
Ivan Dejanovic

First I would like to thank all the Mozillians that have put, and are putting great effort in improving Firefox development tools.

I have been using Firebug for a long time even before development tools where a part of Firefox if I am not mistaking. In my company Firebug is still “official” web development tool. But what I have seen as a true Firebug fan is how much Firefox development tools have progressed and how better they are with each Firefox version.

I have not installed Firebug at my home computer and all my off the clock development is being done using Firefox development tools. I have done this in order to give Firefox development tools an honest chance. With out any fall back I can go to I have to use Firefox development tools and create completely objective opinion.

What I have determined is that the gap between Firebug and Firefox development tolls is getting smaller and smaller. I believe that Firebug is still a better tool but not by much. One big advantage Firefox development tools have is that they are noticeable faster then Firebug.

I wish you success with Firefox developent tools. Please keep up with good work.

September 24th, 2013 at 11:15
1. Jeff Griffiths
  
  Ivan: thanks fro the comment! I really appreciate the feedback, and I agree that we’ve come a long way in the last while.
  
  If you have some time, what is really valuable to us is to know what the remaining features are from Firebug that are either not as useful to you or completely missing from the Firefox Developer Tools. This kind of feedback is really important to us. Feel free to comment here, log bugs in bugzilla or post to the mailing list:
  
  https://lists.mozilla.org/listinfo/dev-developer-tools
  
  September 24th, 2013 at 13:14
  1. Jeff Carlsen
    
    I’ve been wanting to reach out and give feedback for a while, but I always stop short because signing up for a mailing list is a massive impediment. You should consider having a Google group like some of the other Firefox teams (if you already do, please forgive my ignorance).
    
    I use the built in developer tools regularly, and there are three things that bother me about the inspector specifically:
    
    1. No visual highlighting of margin and padding.
    2. Color values are always translated to rgb() color. I need them in their original format.
    3. I can’t edit HTML directly.
    
    September 25th, 2013 at 09:05
    1. jamEs
      
      I mentioned #1 above, but those other 2 points are definitely good ones.
      
      September 26th, 2013 at 05:33
      1. Mike Ratcliffe
        
        1. No visual highlighting of margin and padding.
        I will be getting onto that after my current task.
        
        2. Color values are always translated to rgb() color. I need them in their original format.
        We may have a way to get the original format soon but in the latest nightly at least you can select the color type in the options panel.
        
        3. I can’t edit HTML directly.
        We also have plans to work on that.
        
        October 6th, 2013 at 13:39
    2. Jeff Griffiths
      
      Oh, sorry for not providing a complete answer. We have a bridge for all of our discussion lists into google groups, for example:
      
      https://groups.google.com/forum/#!forum/mozilla.dev.developer-tools
      
      September 26th, 2013 at 08:45
Fernando Briano

I’ve been using Firefox Developer Tools for a while now and haven’t gone back to Firebug. Using Aurora helps having bleeding edge features :)

I translated this post to Spanish on my blog, respecting the CC license:
http://picandocodigo.net/2013/firefox-developer-tools-parte-1-la-consola-web-y-el-debugger-javascript/

Keep up the good work and thanks!

September 25th, 2013 at 01:38
1. Robert Nyman [Editor]
  
  Good to hear! And thank you very much for the translation!
  
  September 25th, 2013 at 04:50
pd

At present, at least in Aurora, Firebug has a massive performance bug. Whenever you switch to/from a tab with Firebug enabled on it, there’s a 5 to 10 second lag. Meanwhile the native tools , IMHO, are uglier, less functional and incomplete. Over at Redmund, they’re tools have taken a quantum leap from being utterly pathetic to being streets ahead of the broken/incomplete Firefox-based tools. Memory profiling, UI responsiveness tools.

*sigh*

I’m sure developers contributing Firebug and native Dev Tools efforts are trying hard but the leadership decision to re-write the Firebug (wheel) and therefore split resources into duplicate projects is currently choking Firefox’s ability to provide the cutting edge in developer tools that it was once famous for. Sad state of affairs. Only Chrome’s native tools are worse. Please, for all those developers currently stuck with buggy debugging tools, take a look at this: http://code.google.com/p/fbug/issues/detail?id=6086

September 25th, 2013 at 09:53
Rohit

Wow! this is good replacement for firebug, it is damn fast. Can we expect Memory profiling support in dev tools, This is missing even in firebug

September 25th, 2013 at 10:33
Raymond Camden

Forgive me if this is explained above and I missed it – but does Firefox’s dev tools have an extension API like Chrome’s does?

September 26th, 2013 at 03:54
1. Jeff Griffiths
  
  Hi Raymond,
  
  Yes there is! We have an initial extension api which is documented here:
  
  https://developer.mozilla.org/en-US/docs/Tools/DevToolsAPI
  
  As well, Victor Porof ( one of the developers ) has a handy template for creating new toolbox extensions on gitub:
  
  https://github.com/victorporof/Restartless-Template
  
  What we have right now is a bit basic compared to chrome’s apis, but there are a few extensions that have been written that do fairly powerful things. What sort of capabilities most interest you?
  
  September 26th, 2013 at 08:50
  1. Raymond Camden
    
    Nothing in particular, just more a “can it be done” – and I’m glad to see it can be. Thanks for the links as well!
    
    September 26th, 2013 at 13:21
Jeremy Smith

This is the first time I’ve used FF in years, and the web console is actually pretty amazing! It has a much better UI than Chrome Dev Tools! I could see switching to it full-time if I could only increase the font size of the inspector.

Does anyone know if there is a hack for this? I tried installing Stylish, but the add-on that claims to increase the font size of the Inspector doesn’t do anything.

September 27th, 2013 at 09:01
1. Robert Nyman [Editor]
  
  Thanks for the kind words! And I’m glad you ask about font size! Yesterday we had a post here on Mozilla Hacks about the new features, where UI zooming is one of them.
  
  September 27th, 2013 at 13:03
Arno.Nyhm

Nice progress

But why there are 2 similar projects?

Why you not combine the knowledge and resources from FireBug and FF DevTools into one?

September 28th, 2013 at 10:31
1. Robert Nyman [Editor]
  
  Thanks. We have a post planned for here at Mozilla Hacks, to explain that. Stay tuned.
  
  September 30th, 2013 at 01:42
Saje Dennis

The built-in Developer Tools in Firefox are remarkable with interesting features which offer unlimited possibilities to web developers and designers. The Web Console and JavaScript Debugger tools, explained in this post, are great and have an excellent user interface.

October 1st, 2013 at 04:12
1. Jeff Griffiths
  
  I’m glad you’re enjoying them!
  
  October 1st, 2013 at 08:52
Marian Kostadinov

One obvious but missing feature is the “Clear” button for the network tab.
The idea is that when you press the button, all records in the network requests list get removed.

Another useful feature is “HTML preview mode” for the response tab. I know it is not urgent but I would help in some cases where the response HTML is not readable.

And I have to say well done for everything. It’s getting better and better and I am now even happier since F12 opens the DevTools.

October 1st, 2013 at 04:42
1. Jeff Griffiths
  
  Marian: thanks for the comment! We are tracking your ‘clear button’ idea in this bug:
  
  https://bugzilla.mozilla.org/show_bug.cgi?id=859057
  
  I agree it would be useful. You can add yourself to the cc list to subscribe to activity on that bug.
  
  As for the ‘HTML Preview Mode’ – I’m having a harder time understanding what your use case is – can you provide more detail?
  
  October 2nd, 2013 at 06:56
  1. Marian Kostadinov
    
    Yes, of course!
    1. Open Chrome.
    2. Go to a site that loads HTML content with XMLHttpRequest.
    3. Open Chrome Inspector
    4. Switch it to Network Tab.
    5. Perform an action that would trigger this XMLHttpRequest.
    6. Click on the row that appeared.
    7. On the right side there is a “preview tab”.
    
    That is what I mean – this tab is missing in FF dev tools.
    
    October 4th, 2013 at 09:12
    1. Jeff Griffiths
      
      Perfect, thanks for replying. :)
      
      October 4th, 2013 at 09:29
Arno.Nyhm

If you become back a html as response. And you like to see this response

Maybe if a snipped of a page is replaced by html from response.

Then it is more easy to check previous responses in network tab in a html preview than with plain html

October 2nd, 2013 at 08:25
João

You talk open but use closed. You are like Saint Thomas, do what I say, don’t do what I do. Using closed source technologies and making free pub to them on a open environment is just a shame. This blog is a shame.

October 4th, 2013 at 02:50
1. Robert Nyman [Editor]
  
  Thanks for the feedback. It would help, however, if you would be a bit more concrete with what you don’t like/agree with, and we could have a proper discussion. Just saying that you don’t like things isn’t very constructive.
  
  October 9th, 2013 at 02:57
Vytautas

Hello,

it’s getting better and better with new releases but it’s still missing very important and helpful feature – console accessible in all tabs. It’s really annoying to go into debugger, break on some execution and then change to console to do something custom.

October 6th, 2013 at 12:27
jaborandi

I noticed there’re some devs of the tools here, so posting some feedback:

1. Old “Error Console” quotes exact line of code where error happened and even pinpoints the symbol. This is always very useful because you see the problem right away, but especially important in frequent cases when line number is detected incorrectly.

2. Dev Tools top menu items – NET / CSS / JS / etc. – are “checkboxes”. As far as I can tell developer normally needs only NET or only CSS or only JS while debugging specific problem. “Checkbox” mechanism makes the process cumbersome, steals your focus (you are interested in JS but need to check what else is ON and turn it OFF, your attention is destroyed), and content of the window by default – crowded.

3. Same NET/CSS/JS… – the style that indicates On/Off: 1) colorized discs always stand out and make everything with them look active anyway; 2) darkness indicates activity (I guess you went for “pale” indicating inactivity, but result is that normal brightness indicates “off” and darkness – “on”); Please check old “Error Console” as a reference – it was very easy to use. In respect of both the look and the way it worked.

October 9th, 2013 at 04:34
Raymond Camden

Can you explain what “Enable Chrome debugging” means in the FF Tools options panel?

October 10th, 2013 at 03:58
1. Robert Nyman [Editor]
  
  It’s for things in the browser chrome.
  From Firefox Developer Tool Features for Firefox 23:
  
  If you have Chrome Debugging turned on, check out the Browser Console. It’s a replacement for the ancient Error Console and gives you a Chrome-context command line for executing JavaScript against the browser. It’s nice and should be enabled by default in Firefox 24.
  
  October 10th, 2013 at 04:49
Raymond Camden

Ok… I may be slow here but I’ve read this twice and I don’t think I understand you. Are you saying the console, by default, does NOT let you run code? Like typing in a variable name to see the value? Because I do not have this option on and I can run code in the console.

Oh… I’m on Firefox 25. I didn’t even realize. Is 23 the standard release?

October 10th, 2013 at 04:57
1. Mike Ratcliffe
  
  “Enable Chrome debugging” allows you to debug Firefox itself. Chrome has always been the name for the JavaScript and XUL inside the browser as opposed to the content area and is not related to Google’s Chrome browser.
  
  When that option is enabled you can go to Web Developer > Browser Console and see messages from inside the browser itself rather than from only in a web page.
  
  The four release channels we have are Nightly, Aurora, Beta and Release. Look at this chart:
  http://media.askvg.com/articles/images2/Mozilla_Firefox_Channels.png
  
  So if I add code to Nightly it will be available in Aurora in 6 weeks time. 6 weeks later it will be available in Beta and then 6 weeks later it is released. This is to ensure stability.
  
  October 10th, 2013 at 08:31
2. Will Bamberg
  
  On running code: there are 2 different consoles, the Web Console (https://developer.mozilla.org/docs/Tools/Web_Console) and the Browser Console (https://developer.mozilla.org/docs/Tools/Browser_Console).
  
  As Mike said, the Browser Console is only made available when you select “Enable chrome debugging”.
  
  Both consoles allow you to run code. But the web console evaluates the code in the context of the current page, so you can just use it to interact with the web content loaded into that page. The browser console evaluates code in the context of the browser itself, so you can use it to control the browser, and even to interact with the browser’s UI.
  
  October 10th, 2013 at 09:56
Raymond Camden

So I just grabbed the main release – which is 24. So is “standard” FF now 24 or 23?

I asked this on Twitter too, but can you explain the differences between 24, 25, Nightly, and Aurora?

October 10th, 2013 at 05:02
1. Robert Nyman [Editor]
  
  We wrote about this a while ago in Firefox and the release channels, and we list upcoming releases on the wiki.
  
  October 10th, 2013 at 13:32
Rohit

I’m not able to copy json response of a network request. This is bad

October 10th, 2013 at 05:46
Raymond Camden

Rohit, I’m not sure what you mean. I just looked at an XHR response. I viewed the JSON, selected all, and copied just fine.

October 10th, 2013 at 07:12
Raymond Camden

Although to be fair, FF is “hiding” the right click menu in the response which seems… awkward and unnecessary. Many folks – like you did perhaps – may assume they can’t copy. I’m going to file a bug report.

October 10th, 2013 at 07:13
Marian Kostadinov

Two more things –
1 – there is no “DOM Listeners” tab in the inspector. I know that the focus here is the styling but DOM Listeners are also important. This feature is available in Google Chrome Inspector.
2 (a bug IMO) – when you select an element, this element in the page is highlighted/displayed with an offset relative to the parent element and “under” the options that are above the selected one. For small selects this is ok but if you have 100 options, the last options are way way down in the page.

October 14th, 2013 at 03:46
1. Mike Ratcliffe
  
  > 1 – there is no “DOM Listeners” tab in the inspector.
  
  We are working on that.
  
  > 2 – when you select an element, this element in the page is highlighted/displayed with an offset relative to the parent element and “under” the options that are above the selected one.
  
  I am not sure what you mean … do you have an image or video? What would you suggest that we do.
  
  October 14th, 2013 at 08:45
  1. Marian Kostadinov
    
    Yes, here are two screenshots:
    
    1. http://crop-factor.net/ff-dev-screen1.png
    2. http://crop-factor.net/ff-dev-screen2.png
    
    is it clear what I mean or you need some more screenshots?
    
    October 14th, 2013 at 11:48
    1. Jeff Griffiths
      
      Marian: thanks for the report, I’ve logged this bug:
      
      https://bugzilla.mozilla.org/show_bug.cgi?id=927105
      
      Please add / correct any of my description, and feel free to cc yourself on the bug in order to track progress. In particular, I’ve speculated on what we might want to do instead – would love to hear your ideas added to the bug.
      
      October 15th, 2013 at 13:41
Andrés Correa Casablanca

The unique point that stops me to use the Firefox Developer Tools is that the debugger has no options to expand and/or prettify the js code (very useful when you have to deal with minified code).

That would be a nice feature to include in the browser, as it’s already done in Chromium and Chrome.

October 17th, 2013 at 02:50
Mike Ratcliffe

Pretty-printing was added in Firefox 27 so it is available from that version onwards.

October 17th, 2013 at 06:45
Ethan Marcotte

Just wanted to commend you guys on the Developer Tools work: seriously, they’re coming along beautifully, and I’m excited to see them evolve.

The two items I’m really missing right now are:

1. Editing blocks of HTML in the Inspector.
2. Editing CSS selectors in the Inspector.

That’s really about it for me. I’m still getting oriented, but so far I’m really enjoying them. Thanks for all the hard work!

October 17th, 2013 at 15:21
1. Mike Ratcliffe
  
  > 1. Editing blocks of HTML in the Inspector
  We have this working very well and it will land soon.
  
  > 2. Editing CSS selectors in the Inspector
  I didn’t realize that this is not possible in the rule view. Bug logged:
  https://bugzilla.mozilla.org/show_bug.cgi?id=928517
  
  October 18th, 2013 at 13:24

Comments are closed for this article.

Hacks

By Jason Weathersby, Robert Nyman [Editor emeritus]

Web Console

JavaScript Debugger

Learn More

Coming Up

About Jason Weathersby

About Robert Nyman [Editor emeritus]

57 comments

Reintroducing the Firefox Developer Tools, part 1: the Web Console and the JavaScript Debugger

By Jason Weathersby, Robert Nyman [Editor emeritus]

Web Console

JavaScript Debugger

Learn More

Coming Up

About Jason Weathersby

About Robert Nyman [Editor emeritus]

Discover great resources for web development

Thanks! Please check your inbox to confirm your subscription.