The Preview You Can Use Now

Mozilla is building a collection of stable, fast and usable developer tools that ship with the browser. I’d like to introduce a collection of improvements that are scheduled to be released in final form on January 31, 2012.

But, you can get them now by downloading the Firefox Aurora channel. I personally find Aurora builds to be quite stable and usable for general browsing and web development. Give it a try and see what you think. You can install Aurora alongside your stable release of Firefox.

The New Page Inspector

Inspect Element Context Menu

Using built-in tools, you can now peek into your page’s structure and layout. Choose “Inspect” from the “Web Developer” menu, or press the handy ctrl-shift-I (cmd-shift-I on Mac) keyboard shortcut, and you can visually select the page element that is of interest to you.

You’ll also find a new “Inspect Element” context menu item that lets you immediately select the element that’s under your cursor.

When you’re inspecting a page, you’ll see something like this:

We overlay the page to highlight the element that you’re working with (1). The highlighter also shows you the tag, ID and classes associated with the page element you’re viewing.

At the bottom of the window, there’s a toolbar that gives you options for changing or working with the selected element. Starting from the left, there’s a close button to close the page inspector and return to normal browsing. The “Inspect” button toggles visual selection mode so that you can highlight another element. ProTip: pressing the ESC key also switches modes.


We call the next part of the toolbar the “breadcrumbs”. They show you where you are in the HTML structure and let you quickly switch to another element. The selected element is the dark “pushed” button. To the left of it are its parents, and to the right one of its children. Just click one of the buttons to move between the page elements. If you click and hold a button, you get a menu that lets you select from the siblings of the element listed on the button. The breadcrumbs make navigation quick without taking up much of your screen.


Sometimes looking at the HTML representation of a page is the quickest way to figure out what’s going on. Click the HTML button and that’s the view you’ll get. There’s a resizer on the right side of the toolbar to set just how much space you want for the HTML view. Also, clicking on a node in the HTML view will select that element for further inspection. ProTip: ctrl-H toggles the HTML view.


Last, but definitely not least, is the Style view. This lets you dive in, explore and experiment with your CSS. It offers two separate views of the CSS attached to the selected element: a CSS rules-based view (left, above), and a properties-based view (right, above).

The rules view is organized much like your stylesheets, showing all of the rules that apply to the element and all of those properties that those rules give you. Properties that are overridden are crossed out. You can toggle any single property easily using the checkbox to the left of it. A single click on a property name or value lets you edit it and see the results immediately on the page. If you click anywhere on the line with the brace at the bottom of the rule, you can add a new property there.

On a page with lots of styles, you sometimes just want to find out what the font-size is set to. That’s where the property view comes in. You can expand the “font-size” property and see how its set and which stylesheet set it. By default, only styles that are set in your stylesheets will be displayed (so you don’t get browser defaults listed). If you have a lot of properties listed, as you might if you use a reset stylesheet, you can quickly find what you’re looking for by typing in the search box.

ctrl-S toggles the Style view.

Web Console + Page Inspector: Great Together

The Web Console is available whenever you want it, even when you’re using the page inspector. If you have an element selected, that element is available to JavaScript in the console using the variable $0.


The Scratchpad feature, which we released in August, gives you a very friendly way to experiment with JavaScript. Rather than being confined to a small input box, you get a whole editor window to work with. Now, Scratchpad uses the Orion code editor to provide syntax highlighting, better indentation and other features you’d expect from a modern code editor.

Scratchpad is now wired into Firefox’s “session restore” feature. This means that you can try out a bunch of code in Scratchpad and if you restart Firefox, restoring your session will also bring back your Scratchpad. Of course, you can always save and reload your Scratchpad files, just as you could before.

If you are only doing web development, we’ve streamlined the user interface. If you’re doing Firefox add-on development, you owe it to yourself to set to true in about:config. That setting allows Scratchpad to run code in a privileged browser context and not just against the current web page.

The console Object

We’ve been building out the console object that you call from your JavaScript code or use at the Web Console’s JavaScript input. It is now in line with the de facto standard, implementing the methods that are standard across browsers. Firebug has a couple of others that we don’t implement yet (console.table, console.profile, console.dirxml), but the commonly used methods are there.

More Is On The Way

All of these features are available now in Firefox Aurora builds. We’re working on getting more new features together for you for the next Aurora.

Check out our Get Involved page to see how you can provide feedback and help make these tools even better.


1. Other web developer tools make changes to your page (for example, adding a class) to make the selected element visible. Firefox’s highlighter does its work without making any changes to your content .↩


Comments are now closed.

  1. patricio wrote on November 16th, 2011 at 11:08:

    I think two nice improvements would be:

    – Add the possibility to detach the inspector and dev tools, as it’d be really comfortable when using multiple monitors
    - Improve/replace the view-source, as when you are using the REALLY nice css properties inspector, and click a link to a stylesheet it takes you to a dull plain text CSS, that doesn’t even have line numbers

    congratulations on the huge progress you have made, I think this is a really important aspect to keep improving of firefox in order to get back all lost devs users who moved to chrome

    1. Simon Gymer wrote on February 1st, 2012 at 06:23:

      +1 for needing to be able to detach it from the main browser window to use on another monitor. Really important for us to be able to do that otherwise there isn’t enough room to work in.

  2. dan wrote on November 16th, 2011 at 11:54:

    What’s up with the ugly scrollbars on OS X?
    Spoils everything else.

    1. Kevin Dangoor wrote on November 17th, 2011 at 08:36:

      I assume you’re using Lion. If I recall correctly, there’s a bug open for Lion-style scrollbars in Firefox. I don’t think the developer tools do anything different with their scrollbars than the rest of Firefox.

  3. Josh T. wrote on November 16th, 2011 at 12:17:

    I think there needs to be syntax highlighting in the Styles inspector.

    Other than that, I’m really happy with this, and I’m using it as a replacement for Firebug, since that’s all I used it for. Thanks a lot for making it, Mozillians. :)

  4. Jon z wrote on November 16th, 2011 at 12:19:

    Awesome! It’s really fast and stylish too.

    Another nice feature would be something to rival the visualization of Firebug’s “Net” tab which helps to organize, navigate and review the http requests made by the page, and more full-featured script debugging (with breakpoints, inline script editing, etc..).

    This is really cool progress and I’m stoked about what’s next.

    1. Kevin Dangoor wrote on November 17th, 2011 at 08:37:


      A debugger is in the works already (and it uses a whole new and improved debugging interface in SpiderMonkey). The network timeline is likely to be one of the next things we tackle.

  5. Kevin Dangoor wrote on November 16th, 2011 at 12:51:

    patricio: we definitely plan to be able to detach the tools from the window.

    patricio and Josh T: We also have some plans for what happens when you click the stylesheet link. Stay tuned!

    I’m happy you like the progress so far!

  6. Robson Sobral wrote on November 16th, 2011 at 13:58:

    Good to know! More features, less addons! Less addons, better performance!

    I just would like to the design of the tools better integrated to the rest of interface.

    1. Stephan Sokolow wrote on November 16th, 2011 at 14:26:

      While I understand where you’re coming from, I actually like a dark Page Inspector. It finally gives me a chance to enjoy some dark, stylish UI elements without turning the entire browser window dark.

      (Now let’s just hope the “native” in-titlebar stop/reload button is just an error in my Aurora so I don’t have to so something stupid/crazy like how I used to force-install the XP-like theme for Vista on my Linux Firefox to get keyhole-style back/forward buttons.

      Even if I were using GNOME rather than LXDE, I really don’t like Firefox’s history of butchering the elegant, distinctive aspects of its look and feel on Linux to better fit in with GNOME.)

      1. Stephan Sokolow wrote on November 16th, 2011 at 16:21:

        Just received Firefox 8 via my package manager. It’s not a bug or, if it is, it’s not been fixed.

        Oh well, that’s what userstyles are for.

  7. Stephan Sokolow wrote on November 16th, 2011 at 14:17:

    I tried this on Aurora a couple of days ago and I love where you’re going with it.

    Light, fast, and only missing two features I still need Firebug for. (At-a-glance visualization of how a node’s dimensions decompose into margins, padding, etc. and the ability to edit the DOM right in the DOM view.)

    Web Console and Page Inspector, as of two days ago, already implement everything I used Firebug for except deleting “Please register” overlays, rapidly iterating a prototype UI to fine-tune a design, figuring out why a node isn’t the shape I expected, and things outside their purview like YSlow and JS breakpoints.

  8. Edwin Martin wrote on November 16th, 2011 at 15:25:

    Looks very nice. But how is this positioned next to Firebug? Every web developer has Firebug installed, so what is this really going to add?

    Not that I want to ruin the party, I’m just curious. Do you eventually want to replace Firebug? Or is this a developer tool for non-developers? Or do you prefer developer tools with shiny graphics? How is this positioned?

    1. Stephan Sokolow wrote on November 16th, 2011 at 16:29:

      I’m rather curious about it myself.

      The audio from indicates that the design principles are to fight the kind of sluggish behaviour you get from having something like Firebug as a monolithic, all-or-nothing blob, but I don’t remember any explicit statement as to which of these cases is intended:

      * Replace Firebug
      * Provide an alternative for most developers but leave Firebug power-users on Firebug
      * Complement a trimmed-down Firebug

      1. Robert Nyman [Mozilla] wrote on November 17th, 2011 at 02:25:

        Right now, at least, the idea is to “Provide an alternative for most developers but leave Firebug power-users on Firebug”. It is basically about offering the features most users need native in the web browser, while those who need to do even more will have Firebug.

  9. Gilmore wrote on November 16th, 2011 at 17:52:

    I like where they’re going, and I especially like the way the element highlighting is done, but there’s still lots of things that need to improve:

    1) Having HTML inspector, style inspector and web console all open at the same time leaves almost no space for the actual page content – I don’t see the need for taking up so much space for HTML+Style. Why not put them in the same panel like Firebug and the WebKit tools?

    2) The Style inspector doesn’t scroll, so if you have a lot of inherited styles you can’t view them without resizing your browser.

    3) The Style inspector doesn’t allow copy+paste, so I can’t copy in-page tweaks I’ve made back into CSS files.

    4) I selected the Properties view in the Style inspector, unchecked “Only user styles”, then switched tabs. When I switched back, the inspector had re-checked the box and hidden the properties I wanted to see.

    5) It’s only early days yet, obviously, but having a visual indication of margin/border/padding on an element would be very useful.

    1. Kevin Dangoor wrote on November 17th, 2011 at 08:49:

      Thanks for the feedback, and we certainly do have more we want to do.

      1) I personally like not having the HTML inspector open at all. Much of the time, I get what I need without it (especially by navigating with the breadcrumbs). The style inspector makes nicer use of the screen real estate.

      All of that said, we will be doing more with how these views are presented and there will be more options available.

      2) That’s a bug:

      3) Yeah, I’ve seen that use case. I’m hoping to have better solutions, but it would be good for copy/paste to work as expected.

      4) Sounds like a bug to me. If you see bugs like that, feel free to file them here:

      That’s an easy way for you to see when things you’re interested in are fixed.

      5) Agreed. There’s a feature page for that.

  10. Aldi wrote on November 16th, 2011 at 18:13:

    Looks great!

    Looks like it’s following the styles of other development tools from other browsers in terms of UI. However, I still find Firebug more intuitive somehow… or is it just me?

    A few things that can at least make it slightly more efficient for quick web development usage:

    Styles > Rules
    -> Make this scrollable
    -> Add auto-complete feature

    Keep it up!

    1. Kevin Dangoor wrote on November 17th, 2011 at 08:51:


      We do still have some interesting new UI bits coming.

      How “intuitive” something is often depends on one’s own personal experience, and I have definitely heard firsthand how different people’s preferences vary between the tools that are out there.

      The scrollability of the rules view is a bug, fix coming soon.

      Auto-complete is definitely a nice thing to have.

  11. Skoua wrote on November 16th, 2011 at 18:27:

    This inspector looks really nice but I don’t really get the point in doing this when we already have FireBug?

    Is this going to be some kind of replacement or light version of it?

    I’d love to have FireBug built-in FF with this UI though.

    1. Kevin Dangoor wrote on November 17th, 2011 at 08:59:

      I’ve written about Firebug and Mozilla’s developer tools here:

      Firebug has millions of fans and many, many interesting features built up over years. That hasn’t changed one bit.

      What we’re building now is fast, built to the same standards as the rest of Firefox, automatically tested with the rest of Firefox and shipped with the browser. Our work builds up new APIs and fixes up old ones that can help make Firebug better.

      Web developers can choose to use the built-in tools or Firebug… whatever helps them get the job done easiest!

  12. seleko wrote on November 16th, 2011 at 22:46:

    Thank you for efforts :)
    Now I cant stop run Chromium for writing page styles :)

  13. magsout wrote on November 16th, 2011 at 23:18:

    Looks very nice. But, there is a technical reason to resize the webpage when you load “Style” ? I think, it’s would be a better idea to add a bottom scrollbar like the highlighter, or like firebug and webkit inspector directly inside the highlighter.

    Gilmore have some good idea, I agree with him.

  14. pd wrote on November 17th, 2011 at 04:05:

    The UI is grossly inferior to Firebug. The inspector appears to perform a lot better though that is just based on a casual glance.This really is such a gross waste of resources. Really, all this re-writing the wheel so that you can just say “we have built in tools too”? It’s ludicrous.

    1. Robert Nyman [Mozilla] wrote on November 17th, 2011 at 04:11:

      There are many factors at play here. Firebug, while a great tool, has lots of legacy code and performance problems. Mozilla wants to have tools native in Firefox, without any extra install, that are better performing and also a better ground for continuously having development tools evolve.

      The idea is also not to replace Firebug, but rather offering tools that does most of the tasks most developers need.

      1. Aldi wrote on November 17th, 2011 at 07:17:

        “Firebug, while a great tool, has lots of legacy code and performance problems. Mozilla wants to have tools native in Firefox…”

        -> So why not use this effort to perfect Firebug instead & make it native, instead of ‘wasting resources re-writing the wheel’ (as @pd puts it)?

        “The idea is also not to replace Firebug, but rather offering tools that does most of the tasks most developers need.”

        -> …which is what Firebug does…

        1. Robert Nyman [Mozilla] wrote on November 17th, 2011 at 07:23:

          > So why not use this effort to perfect Firebug instead & make it native

          For a number of reasons. Firebug stems back from 2006, with LOTS of code and features that will, most likely, never be in the native Developer Tools in Firefox. Also, the time to go through and adapt all that code would likely take a lot longer than building new tools.

          Firebug is much more powerful with more features, extensions written by third-party developers and a lot more dependencies than you would want to build into every version/release of Firefox.

          1. Aldonio wrote on November 17th, 2011 at 12:16:

            > Also, the time to go through and adapt all that code would likely take a lot longer than building new tools.
            Whereas you have a valid point regarding time, It would be still better if Firefox & Firebug dev teams join forces to make a robust and unique product, having two diferent development tools will be overkill at the end since you will have redundant code doing the same thing in a different way…

  15. Raphael wrote on November 17th, 2011 at 07:30:

    There has been a lot of discussion on where this falls short of FireBug but in what areas do people think it does more?

    It seems that the scratchpad is one area that it does more.

    Everything else seems to be really really well covered by Firebug.

    Is there a noticeable performance difference?

  16. Dharmesh wrote on November 17th, 2011 at 17:34:

    It is alt-s and alt-h to toggle HTML and CSS view in Windows.

  17. Alistair wrote on November 17th, 2011 at 22:18:

    I agree with the above sentiments.

    I can’t see a reason to have both. Either kill firebug as an add on and focus all resources on advancing the Firefox dev tools, or just have firebug and focus on that.

    I can’t see much point in having cut down dev tools.

    1. Robert Nyman [Mozilla] wrote on November 21st, 2011 at 06:55:

      The difference is that there are other developers on Firebug, and it’s not owned by Mozilla. Even though we have an overlap with one person, it’s not a matter of Mozilla putting lots of resources into both projects, .

  18. Robert Nyman [Mozilla] wrote on November 18th, 2011 at 01:28:


    I see your point, and some parts of the tools will do the same things. As a whole, though, they are two different tools and approaches with different goals.

  19. Neil Osman wrote on November 20th, 2011 at 03:14:

    I would love to see firefox and firebug join efforts to integrate firebug into firefox

    1. Robert Nyman [Mozilla] wrote on November 21st, 2011 at 06:56:

      There are kind of joined efforts in the sense that one of the main Firebug developers is also helping out with the developer tools in Firefox. It is not clear yet where this will lead in the future.

  20. Bob wrote on November 21st, 2011 at 10:38:

    Will it be possible for developers to extend theses developer tools? Like in Firebug?


    1. Kevin Dangoor wrote on November 21st, 2011 at 10:45:

      Yes! In fact, there are some people who have already created a “Font” panel that plugs into the page inspector view.

      Let us know what kinds of add-ons you’d like to write, and we can help you get there.

  21. Brandon Benvie wrote on November 21st, 2011 at 14:16:

    This needs to be detachable and it needs a way to either export the features into Firebug or a way for Firebug to import additional features and Firebugize it. I appreciate the fine line that needs to come between the internal and external but it’s not going to be fun as a developer when I have to switch between the two because the internal CSS editor is clearly far superior to anything that could be made externally, yet can’t work alongside some UI. When I develop I’m hittin javascript, css, html, and network stack one after another when working on complex issues. This won’t work with that need.

  22. Brandon Benvie wrote on November 21st, 2011 at 14:29:

    This picture is illustrative:
    Note the already minimum configuration being used for the chrome/toolbars.

    1. Robert Nyman [Mozilla] wrote on November 23rd, 2011 at 03:32:

      Thanks for the picture and the input. The hope is that there will be other ways to combine the views in the future to make things like that better and easier to overview.

  23. James wrote on November 21st, 2011 at 16:41:

    Things holding me back from using the native inspector is the fact that I can’t select different pseudo classes like in firebug, I would really like them to add the ability to choose :focus, :hover, :active or :visited. the other thing is that you can’t currently view are the pseudo elements. I assume these are on the way? Other than that I really like the new inspector and am excited to start using them once they are a little more fleshed out.

    1. Robert Nyman [Mozilla] wrote on November 23rd, 2011 at 03:32:

      Good feedback, thanks!

  24. Rahul wrote on November 28th, 2011 at 11:46:

    I am loving these features, thank you so much and thumbs to mozilla team for developing variety of developer tools.
    1. Do you have any plans to bring validation tools for HTML and CSS build in firefox?
    2. Any colour picker tools, there are addons for this, but it would be nice to have this feature..

  25. Rahul wrote on November 28th, 2011 at 11:57:

    And also, please give a thought on web accessibility features
    3. Colour text readibility
    4. Colour contrast ratio analyser

  26. Kevin Dangoor wrote on November 28th, 2011 at 12:46:

    Hi Rahul,

    We don’t have any plans at present to build in HTML and CSS validators. Thanks for suggesting it! We do have to figure out where the right line is as far as what is built in and what remains an add-on.

    We do have plans for a color picker, and those are great suggestions as far as accessibility goes.

    1. Skoua wrote on November 28th, 2011 at 15:32:

      At least the ability to open a new tab with Unicorn and our url sent to it would be nice IMO.
      Or the page content if we’re working on localhost.

  27. Rahul wrote on November 28th, 2011 at 21:24:

    Thank you so much kevin for your reply..the validation tools are built in web developer add on, i use it for validation purposes..and for rest firebug works awesome..i’ll be waiting for your next step in bringing some new features in tools and except these features what are the new tools you are working on

  28. Marco Campos wrote on December 1st, 2011 at 06:41:

    great work, i can’t wait to see it finished!
    they said about combining the windows, as i tested out, if you open all the built-in developer tools in aurora there is a lot of windows, not so much space for the site we are trying to inspect and the ui of the windows is not much consistent; so it would be nice to see the tools combined in one place.

    the effort of mozilla and firebug in working together is nice, as i see, the way to keep both up and running is having a built-in tool/api in firefox that firebug can extend as a add-on, it may remove some legacy code from firebug too, making it a power tool that improves the already existent dev tool.

    having a javascript inspector with stack view capability is one feature i’d like to see.
    a net analyzer that shows http requests is also a cool feature.

  29. Kenneth Pedersen wrote on December 1st, 2011 at 11:02:

    Thank you very much for these new features! I’m sure it will make a big difference for our productivity in the daily work with developing websites :)

  30. Evert wrote on December 1st, 2011 at 14:57:

    Well, this will clearly divide the deeloper-community in two. Those eager to see this new tool grow over the next few years into something, hopefully, similar to firebug. And those -like me- that are simply afraid this will mean we will end up with worse tools to do our jobs. But even so, we will probably adapt.
    The thing that worries me is that firebug is, despite its age and legacy code, a grown up product which a lot of people have come to love and depend on. Suddenly being confronted with the fact that this will probably change in the future into something that -at the moment at least- looks like a high-school project in comparison (mind you IN COMPARISON, I am not saying it is) is a bit disappointing to put it mildly.
    Frankly I would have been much happier if you bought up firebug and spent extra resources to update the code. Because I doubt very much it will be quicker to rebuild something of equal value in less time.

    1. Kevin Dangoor wrote on December 2nd, 2011 at 06:40:

      Firebug is great and has pioneered a lot. It’s still around, and Mozilla continues to invest in Firebug on the same basis we have for the past 3+ years (see )

      People can continue to use Firebug as long as they want. And, as mentioned elsewhere in the thread, Firefox is getting new and improved APIs that Firebug can take advantage of.

      “Frankly I would have been much happier if you bought up firebug and spent extra resources to update the code. Because I doubt very much it will be quicker to rebuild something of equal value in less time.”

      I can appreciate the sentiment, but we assessed the situation differently. For reasons such as how Firebug is structured and how Firefox has changed since Firebug started and how Firefox is changing with new capabilities, building new tools was the best choice.

      In the meantime, Firebug 1.9 is coming out in 3-4 weeks.

      Web developers can choose their tools of choice (and there are a lot of others available as well, as seen in Robert Nyman’s recent post on Hacks).

      1. Evert wrote on December 2nd, 2011 at 07:12:

        I would agree with you completely, were it not that we are far from sure that firebug will continue to be developed. Esp. since the lead Firebug programmer has taken a job with Chrome as we can read here: so in the end (long or short run, we won’t know) I suspect firebug will become either discontinued or a dead tool.

        So basically my fear is we will end up with a dev tool that is less than we have now (no progress but regress) be it a stripped down copy of firebug you present here of a no-longer-maintained version of firebug.
        I see and hear nothing to set my fears to rest?

        1. Kevin Dangoor wrote on December 2nd, 2011 at 07:50:

          Fear not, because Firebug is not leaderless. The old leader of Firebug (John J. Barton) left IBM to work at Google. Jan (Honza) Odvarko has been working on Firebug full-time for years and managing its releases, and he naturally stepped into the role when John stepped down.

          Plus, Firebug has a community of its own. Not many open source projects have 2.5 million daily users! There are other developers who work on it. It’s open source, JavaScript/HTML/CSS. People can hack on it and people do.

          Not only is Firebug still an ongoing project (new release coming, right?), but what I’m presenting here is certainly not the last you’ll see. These tools will improve over time and be joined by other new features.

  31. Dan Blumenthal wrote on December 1st, 2011 at 19:54:

    Thanks for making me aware of what’s going on. Like all of us I use Firebug. Nice to hear there’s something new and better featured coming out.

  32. Webstandard Blog (Heiko) wrote on December 2nd, 2011 at 01:46:

    I think it is a very good decision, to implement developer tools by mozilla. Because, less external extensions are gooing to start the browser faster. Thx for implementing the tool and thx for sharing those news!

  33. Simon wrote on December 2nd, 2011 at 02:08:

    Great news !
    I hope that can replace firebug in the best !

  34. ad4z wrote on December 2nd, 2011 at 02:53:

    Looking good overall.

    I’d suggest to add functionality of changing CSS numeric values with arrows up/down just like in firebug (up/down = +1 / -1, shift + up/down = +10/-10, ctrl + up/down +0.1/-0.1), does it make any sense?

    Apart from that it’s looking promising!

  35. Mister M. wrote on December 2nd, 2011 at 05:21:

    I’d surely like to see these builds appear as a portable version, instead of needing to install them.

    1. Kevin Dangoor wrote on December 2nd, 2011 at 06:43:

      I believe Aurora and Beta are built in the same way Firefox is with the same installation routines. You can have them installed alongside your main Firefox and there are some plans to make managing multiple Firefoxes easier.

      It’ll only be 2 months before these are in final release… so you can also wait until then.

  36. Pablo Fernandes wrote on December 2nd, 2011 at 12:14:

    i hope you guys can do something different of the current chrome inspector. Should be great have to use both tools during development.

  37. Brian Fenton wrote on December 2nd, 2011 at 15:27:

    Without wishing to sound too negative, I think the problem you’re going to run into is the old Joel Spolsky chestnut, that everyone uses a different 20%. People are going to moan that their favourite Firebug feature is missing, and your problem will be that each person has a slightly different 20%. You can already see that happening in the above comments. Joel’s article

    1. Kevin Dangoor wrote on December 5th, 2011 at 06:58:

      Actually, Joel has a couple of articles that would tell us not to do what we’re doing :)

      Of course, Joel himself said not to make your own programming language and then did so anyhow. Sometimes the problems you’re trying to solve require a certain kind of solution.

      I do think that 80/20 generally applies, but I also agree that people will have their own pet features in Firebug (which has many, many little features). The great thing is that people can choose what suits them best.

  38. Regnareb wrote on December 3rd, 2011 at 05:12:

    Why not reusing Dragonfly who is one of the best (if not the best) developer tools out here, and it’s open source (BSD licence) !

    1. Kevin Dangoor wrote on December 5th, 2011 at 07:01:

      Dragonfly is a nice product, to be sure. But, there are still other things we want to do that will become apparent in future releases (or for people who get involved with the project!)

  39. zahidul hossain wrote on December 3rd, 2011 at 06:08:

    seems gr8………..moving on aurora version

  40. Oğuz Çelikdemir wrote on December 3rd, 2011 at 11:44:

    I would like to see CSS editing capabilities like Skybound Stylizer. In my opinion, If you want to do a new things, you must different from competitors. When I saw the screen shots, I thought “Mozilla will replace their engine with webkit”. Be more specific.

    For instance, If you decide to make a CSS editor like Skybound Stylizer in Aurora, take into account the css property changes. You can show those changes in a simple tab include selectors as well.

    1. Kevin Dangoor wrote on December 5th, 2011 at 08:26:

      This post is largely focused on what we have actually shipped in Aurora 10. Generally, you can find out about plans for future things on our feature pages:

      I wasn’t familiar with Skybound Stylizer, but I do agree with the idea about taking changes into account. It is something we’re discussing.

  41. brentonanthony wrote on December 6th, 2011 at 16:03:

    youtube is not worken. because is got to anti-virus or something else.
    but i just need help to get it fix. i went to firefox to get youtube work.

  42. Saeed Neamati wrote on December 7th, 2011 at 08:20:

    I just can say “Wow!”. With these tools, imagine how easy web development and design would become. This was a great news. Thanks.

  43. Corban Brook wrote on December 7th, 2011 at 10:00:

    One of the things I often want to do is the ability to inspect and element, and then run javascript operations on that element. In chrome I usually select the element in the elements pane, manually edit the markup and assign it an id, then query select the element from the console to assign it to a variable to play with. What would be really nice is if merely by selecting the element in the inspector it would automatically be assigned to window.inspector.selectedNode or something similar so I could easily begin playing with it in the console.


    1. Kevin Dangoor wrote on December 8th, 2011 at 06:44:

      If you select an element and open the console, you can use the $0 variable in the console to refer to the selected element. (Handy tip: this works in Firebug and Chrome as well!)

  44. Ray M. wrote on January 4th, 2012 at 18:40:

    Agree with #comment-1045178

    People are get used to the panel layout like Firebug and Webkit tools. Also the CSS panel on the right hand narrows main content area, which will break layout of many pages, unless to work on the big and wide screen.

    1. Kevin Dangoor wrote on January 23rd, 2012 at 14:05:

      We are working on new layouts for tools.

  45. Andriy wrote on January 13th, 2012 at 15:14:

    You will be planning debugging IndexedDB in your tool in future (like WebSQL in WebKit)?

    1. Kevin Dangoor wrote on January 23rd, 2012 at 14:05:

      Yes, we will doubtless add support for IndexedDB inspection and troubleshooting, but we have other priorities in line ahead of that.

  46. Sam wrote on February 7th, 2012 at 10:23:

    Is there any way to disable the “Inspect Element” in the context menu?

    It’s a nice addition, but as I’ll be sticking with Firebug for the time being, I now have two “Inspect Element” options in the menu, one above the other, and I’m constantly hitting the wrong one. Would be nice if I could remove it.

    1. Kevin Dangoor wrote on February 8th, 2012 at 08:58:

      Unfortunately, the one way to turn off the context menu item is a bit heavy handed right now. If you go into about:config, you can set the pref


      to false (just search for “inspector” and you’ll find it quickly enough).

      This completely turns off the feature, so it won’t even be in the Web Developer menu should you want to, say, use the awesome 3D view that is available in Firefox 11 (now in Beta).

      1. Sam wrote on February 8th, 2012 at 09:04:

        That’ll do, cheers. I use the Tilt plugin (guess that’s like the 3D thing in FF11?) so can live without the dev tools for now…

        1. Kevin Dangoor wrote on February 8th, 2012 at 09:24:

          right, the Tilt addon is a little out of date but still works (and has other random features that we didn’t uplift into the main tools).

          BTW, if you have specific things that keep you on Firebug, it would be great to hear what they are. All of those data points help us focus our efforts on the things people are most commonly trying to do.

          1. Aldi wrote on February 8th, 2012 at 16:58:

            Here’s one thing that keeps me on Firebug… Having the HTML & the Style Inspector side by side just as Firebug does… and the ability to search through the HTML Inspector.

  47. Aman wrote on February 8th, 2012 at 12:43:

    1. Recur the great need for a much compact layout. Although the UI looks very impressive the need for a compact nature cannot be stressed enough. Please let know designers know that some things are just right and need not be changed drastically in an effort to stand out. The GC inspector is not very different from FireBug but nobody called them uninspired. All of this is not to say that I dont like the theme, its awesome but convenience ranks above looks.

    2. It would be nice to have the CSS properties listed in an alphabetical order under the “Rules” section (they seem arranged randomly right now).

    3. The inspector seems to be very greedy and does not relinquish control. Every time I hit “return” in this textarea with the Inspector present even if minimized to the narrow bar, it toggled the “Inspect” feature instead of entering a new line as I wanted it too.
    Note – I could use the alphanumeric keys with the inspector turned on but not the “arrow keys” or the “return” key which was very misleading!

    4. Definitely need a layout inspector to view actual element dimensions.

    5. Every time I inspected an entry under the any section in the “Web console” it opened a new window leading to a huge collection of pop up windows left to be closed!

    6. The “Net” section in the “Web console” needs to be much detailed than its present state. GC style separate Net section or FireBug style inline section would be much preferred than the popup style.

    7. JavaScript inspector and debugger are also very desirable.

    I am positive you must have recognized these needs and are already working towards a better product but a 3D look before a JS inspector just doesn’t inspire confidence.

    Lastly, I would like to offer my thanks for providing us with a cool product and look forward to seeing it improved and possibly eliminate the need for external developer tools.


    1. Aman wrote on February 8th, 2012 at 12:47:

      Oh and the inspector does not work on my personal computer (Fedora 16, 64 bit)

      1. Kevin Dangoor wrote on February 9th, 2012 at 09:38:

        When you say “the inspector does not work”, do you mean the 3D view?

        1. Aman wrote on February 9th, 2012 at 10:45:

          No, I meant the black bar for the inspector did not show up at all!(The 3D view is already available?)
          Also I could not close Firefox if I had multiple windows open(the pop was an empty confirmation box). Last night in my software updates manger, I had another update for firefox. That update fixed the inspector and Firefox.
          Also Firefox 9 used to crash a lot on ajax requests during the development on the product I was working on. All of these are fixed with the update.

          Thank you for the wonderful product.

          PS – A reason I use GC is it allows me to have the incognito window and normal window open simultaneously. Helps when I want to login as different users into my applications. This happens more than you would expect. A feature like that would be greatly appreciated as well.

          1. Kevin Dangoor wrote on February 9th, 2012 at 10:57:

            Oh, sorry, I misunderstood. The 3D view comes in Firefox 11 (slated for mid-March, currently in Beta)

            I have not heard reports of page inspector not opening at all.

            I’m happy to hear that the crashing problem you had encountered is fixed!

            Yes, the Chrome incognito mode is nicely done, and I am certain there have been discussions around that for Firefox. I personally use multiple profiles (a bit hard to get going initially… launch Firefox from the command line with -ProfileManager), because then I can have different Firefoxes running at the same time but not conflicting with one another.

            That’s a different part of Firefox and I don’t know how the priorities shake out there. I do know that some form of that feature is under consideration.

    2. Kevin Dangoor wrote on February 9th, 2012 at 09:37:

      Thanks for the feedback, Aman.

      1. we are definitely still making UI improvements here, including the ability to put the controls in a separate window. keep an eye out here for future release announcements

      2. the “Properties” view is alphabetized. The “Rules” view is in specificity order.

      3. You should close the page inspector before interacting with the page. The page inspector binds a bunch of keys to make them useful while navigating elements for inspection.

      4. layout view is in the works!

      5. there are pluses and minuses there, but generally I agree with you and we are looking at options

      6. same for this. we are currently deciding how we want to approach the equivalent of a “network panel”

      7. javascript debugger is in the works (the first bit of code just landed on Tuesday)

      Also, I’ll note that the 3D view was created as a Google Summer of Code project last summer and then simplified and polished for inclusion in Firefox. If we didn’t already have the code, we would have certainly been working on other features ahead of that one. Sometimes things make it into the product at unpredictable times (especially in open source!)

  48. Aman wrote on February 9th, 2012 at 11:05:

    Congratulations on the advancement on the JS debugger,
    I understand the need to bind keys. Its just that binding only certain keys while leaving the rest free felt misleading.


  49. burk wrote on March 3rd, 2012 at 09:43:

    Bleh. Now I have two “Inspect Element” in the context menu, one from Firefox, and one from the FireBug addon. That said, the Firefox Inspect lacks the ability to delete HTML elements… it’s not yet ready to replace FireBug, if intended.

  50. mmrtnt wrote on May 11th, 2012 at 16:59:

    I agree. I love to use FireBug to take out annoying animations on a one-time basis when I’m trying to read.

1 2

Comments are closed for this article.