Developer Tools in Firefox Aurora 10

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.

HTML

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.

Styles

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.

Scratchpad

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 devtools.chrome.enabled 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.


Footnotes:

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

View full post on Mozilla Hacks – the Web developer blog

Tagged on: , , ,

20 thoughts on “Developer Tools in Firefox Aurora 10

  1. Robert Nyman

    Aldonio,

    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.

  2. Alistair

    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.

  3. Aldonio

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

  4. Kevin Dangoor

    I’ve written about Firebug and Mozilla’s developer tools here: http://blog.mozilla.com/devtools/2011/05/25/the-relationship-between-firebug-and-mozilla-developer-tools/

    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!

  5. Kevin Dangoor

    Thanks!

    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.

  6. Kevin Dangoor

    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: https://bugzilla.mozilla.org/show_bug.cgi?id=700770

    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: https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Developer%20Tools

    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. https://wiki.mozilla.org/DevTools/Features/LayoutInHighlighter

  7. Kevin Dangoor

    Thanks!

    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.

  8. Kevin Dangoor

    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.

  9. Raphael

    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?

  10. Robert Nyman [Mozilla]

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

  11. Aldi

    “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…

  12. Robert Nyman [Mozilla]

    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.

  13. pd

    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.

  14. Robert Nyman [Mozilla]

    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.

  15. magsout

    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.

  16. Skoua

    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.

  17. Aldi

    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!

  18. Gilmore

    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.

Leave a Reply