Mozilla Hacks

CSS source map support, network performance analysis & more – Firefox Developer Tools Episode 29

Avatar photo By Brian Grinstead, Robert Nyman [Editor emeritus]

Posted on February 11, 2014 in Developer Tools and Featured Article

Firefox 29 was just uplifted to the Aurora release channel. This means that it is time to report some of the major changes that you can expect to see inside of the Developer Tools for this release.

Better Looking Tools

In addition to new features, we have been updating the look and feel of our dark and light themes. The light theme has been completely overhauled, and both themes feature a more consistent design throughout the toolbox. Your current theme can be changed from the Toolbox settings. (development notes)

Network Monitor

The Network Monitor now shows you how long it takes the browser to load different parts of your page. This will help measure the network performance of applications, both on first-run and with a primed cache. (development notes)

To open the performance analysis tool, click the stopwatch icon in the network panel. For more information, watch the screencast below or read more on MDN.

You can now copy an image request as a Data URI. Just right click on the image request, select the item from the context menu, and the Data URI will be on your clipboard. (development notes)

Inspector

We’ve updated the inspector highlighter behavior to bring the highlighting functionality more in line with other tools. (development notes)

CSS transform preview tooltips have been added to the CSS rule view. Now, if you hover over a CSS transform, you will get a tooltip with a visualization of the transform. Grab a download of Firefox Nightly or Aurora and try it out on some live CSS transfom examples. (development notes)

CSS rule view now supports pasting multiple CSS declarations at once, like background: #ccc; color: red. (development notes).

Just like in the network panel, you can now copy <img> elements as Data URIs. (development notes)

Style Editor

CSS source map support has been added to the Style Editor. (development notes), and CSS properties and values will now be autocompleted in the Style Editor. (development notes)

Want to read more? We have published a post with more information about using source maps in DevTools to live edit Sass and Less.

Debugger

We have added a classic call stack list in the debugger next to the list of sources. (development notes)

There is a new ‘enable/disable all breakpoints’ button in the debugger. This will toggle the active state of all existing breakpoints at once, to allow switching between normal usage and debugging quickly. (development notes)

You can now highlight and inspect DOM nodes from the debugger. If you hover a DOM node in the variables listing it will be highlighted on the page, and if you click on the inspect icon the node will be opened in the inspector tab. This feature is also available in the console output. (development notes)

Pretty printing now preserves code comments. We are using the open source pretty-fast pretty printer, so it should be pretty fast. If it isn’t, be sure to let us know. (development notes)

Console

console.trace improvements. The call stack is shown inline with other output, and includes links to access each line in the debugger. (development notes)

We’ve also improved console object output to show additional information based on the object type. (development notes)

Code Editor

The code editor can be seen throughout the tools in places like Scratchpad, Style Editor, and Debugger. Here are some of the updates you will see in this release:

  • Code folding in the editor. (development notes)
  • Emacs and VIM keybindings are now available in the code editor. To enable them, open about:config, and set “devtools.editor.keymap” to either “vim” or “emacs”, then restart DevTools. (development notes)
  • ES6 syntax highlighting support (development notes)

Big thanks to all of our DevTools contributors this release (43 people)! Here is a list of all DevTools bugs resolved for Firefox 29.

Do you have feedback, bug reports, feature requests, or questions? As always, you can comment here or get in touch with the team at @FirefoxDevTools.

About Brian Grinstead

More articles by Brian Grinstead…

About Robert Nyman [Editor emeritus]

Technical Evangelist & Editor of Mozilla Hacks. Gives talks & blogs about HTML5, JavaScript & the Open Web. Robert is a strong believer in HTML5 and the Open Web and has been working since 1999 with Front End development for the web - in Sweden and in New York City. He regularly also blogs at http://robertnyman.com and loves to travel and meet people.

More articles by Robert Nyman [Editor emeritus]…

38 comments

  1. Mindaugas J.

    This list looks very impressive. Esp. debugger/console. Awesome work. I’ll be sure to test it soon.

    February 11th, 2014 at 10:18

  2. Stefan B

    Pretty pretty pretty good!

    February 11th, 2014 at 10:54

  3. Tin Aung Lin

    This is awesome and cute. Leap forward to a better functional and pretty world.
    Working with Firefox DevTools would not be painful as back then.

    Thanks
    Tin Aung Lin

    February 11th, 2014 at 11:24

  4. Thomas

    Great update!

    One thing,
    Should the order of the resources in Prime cache and Empty cache be the same? Often they are not.

    Thanks!

    February 11th, 2014 at 11:42

    1. Victor Porof

      No, they’re ordered by the total requests size.

      February 11th, 2014 at 11:49

  5. tarsolya

    Search across all sources? :)

    February 11th, 2014 at 12:38

    1. tarsolya

      Scratch that, found it :) How could I missed that.

      February 11th, 2014 at 12:42

      1. Brian Grinstead

        No problem :). Just for other’s reference, the list of filter shortcuts while searching sources in the debugger is available here: https://developer.mozilla.org/en-US/docs/Tools/Debugger#Script_filter. To search across all sources, you can start the search with a ‘!’ character.

        February 11th, 2014 at 12:51

  6. al3xa

    It would be nice if one could inspect DOM element from Console/Scratchpad. Not to mention long-awaited completion in Scratchpad. But it rocks! Transform preview and Emacs bindings – awesome!!!

    February 11th, 2014 at 16:47

    1. Brian Grinstead

      Thanks! We have a bug opened for hovering / inspecting DOM elements from the console: https://bugzilla.mozilla.org/show_bug.cgi?id=757866. I will check about in the Scratchpad – I would expect that it should be doable now that https://bugzilla.mozilla.org/show_bug.cgi?id=952277 landed, since it uses the same component for displaying the object as the debugger does.

      February 11th, 2014 at 20:16

      1. al3xa

        Cool, thanks for the feedback! I’ll keep an eye on that.

        February 12th, 2014 at 00:47

      2. robcee

        Brandon Benvie is working on integrating tern.js with the scratchpad for autocompletion. Not sure he’s working out of a bug or not yet.

        February 12th, 2014 at 09:58

    2. Mike Ratcliffe

      What you can do is inspect a node using the inspector and then reference that node in Scratchpad or the web console using $0

      February 12th, 2014 at 03:18

  7. keripix

    Oh no, Firefox 29 is still far away

    February 12th, 2014 at 01:37

    1. Brian Grinstead

      Yes, but if you grab a copy of Aurora (https://www.mozilla.org/en-US/firefox/aurora/) or Nightly (http://nightly.mozilla.org/) then you can start using these more up to date tools right now.

      February 12th, 2014 at 05:56

  8. Matěj Cepl

    Still hoping for some way to investigate current resources (application cache, localStorage, indexedDB). I don’t use Chrome for anything, but this is the last temptation I have.

    February 12th, 2014 at 07:00

    1. Brian Grinstead

      Yes, this is much needed, and is being worked on. You can track the progress here: https://bugzilla.mozilla.org/show_bug.cgi?id=926449

      February 12th, 2014 at 08:59

  9. Fernando

    Hello!

    What about clarify which script is calling `console.log` (or showing any other message in the console) as Chrome does, with support do Source Maps? It will be excelent for the most frontend developers, i think.

    Maybe just for the neeeext Firefox, but it will be good, too. =)

    Thanks

    February 12th, 2014 at 10:20

    1. Brian Grinstead

      There is a link next to a logged message that includes a link to the file and line where the console.log was called. Source map support is not yet added for this feature, but progress can be followed at: https://bugzilla.mozilla.org/show_bug.cgi?id=952127

      February 12th, 2014 at 10:40

      1. Fernando

        Wow, thanks!

        Seems like that what i suggest is in the following issue: https://bugzilla.mozilla.org/show_bug.cgi?id=670002 , and it seems not updated recently :/

        But all good. Thanks for the answer, anyway! =)

        February 12th, 2014 at 17:02

  10. Mike

    Love the speed with which FF devtools are improved. Any chance of implementing https://bugzilla.mozilla.org/show_bug.cgi?id=962491 (or something similar) at some point? It would make debugging CSS added by JS events so much easier.

    February 12th, 2014 at 13:04

    1. Brian Grinstead

      Thanks for the feedback! I’ve responded on the bug so we can talk more about it there.

      February 12th, 2014 at 16:56

  11. Nitij

    Looks cool..!!

    February 12th, 2014 at 22:46

  12. Christian

    When I get the Aurora or Beta releases of Firefox they overwrite my current version of Firefox so that I can only use one. I’m not much of a Chrome fan but at least with Chrome I can download and use Chrome Canary AND still use the current version of Chrome separately. Or perhaps this issue has been fixed with Firefox since the last time I checked?

    February 13th, 2014 at 01:44

    1. Victor Porof

      You can certainly use different Firefox versions at the same time. Take a look at this: https://developer.mozilla.org/en-US/docs/Mozilla/Multiple_Firefox_Profiles

      February 13th, 2014 at 02:45

  13. Ivan Dejanovic

    I must honestly say you made great progress in the last two years with development tools. There are some problems I noticed and I don’t know if you have then in your issue tracker.

    If I attempt to perform cross origin ajax request, I always do this by mistake usually a typo, Chrome print a clear error message in the console. Firefox just eats my attempt and I get no feedback.

    If I have an error in my script which causes an exception to be thrown at page initialization Chrome let me open the problematic script put a break point and figure out what is the problem. Firefox don’t show the problematic script in Debugger panel. Some times even scripts that are OK are not shown in Debugger.

    If I make development tools window narrow, some times it is necessary, Console, Inspector, Debugger get left only with icons but if windows is really narrow icons start “falling of the window” on the right. So I can not access all of the options. It would be nice to some times use narrow development tools window when I work on small screen.

    Please fix these issues, especially the first two, if you are able. I believe it is a shame that some times I have to resort to Chrome to figure out stuff.

    Keep up with the good work.

    February 13th, 2014 at 07:14

  14. Omega

    YES! The glowing Popsicle sticks are gone! The new highlight behavior is very handy.

    February 13th, 2014 at 11:44

  15. toupeira

    Awesome improvements! The devtools have matured enough that I feel comfortable with them now and can finally remove Firebug.

    There are still some minor nitpicks though:

    – The monospace font size is still too small on Linux, I was able to workaround it by adding “.devtools-monospace { font-size: 100% !important; }” to userChrome.css, why isn’t this the default?

    – The object inspector in the console still can’t be closed, except by closing and reopening the console

    – Object literals don’t work in the console for some reason. e.g. “{}” returns “undefined”, “{ foo: ‘bar’ }” returns “bar”, and “{ foo: ‘foo’, bar: ‘bar’ }” raises a SyntaxError

    – The Vim keybindings conflict with some devtools keys, e.g. Escape while editing HTML in the inspector leaves the HTML edit mode instead of Vim’s insert mode, and the Ctrl+] shortcut to switch between panels is swallowed by the Style Editor

    February 13th, 2014 at 12:48

    1. Brian Grinstead

      Regarding font size on Linux, there has been a discussion about this (it sounds like some people have different results, especially if they had changed the system-wide default): https://bugzilla.mozilla.org/show_bug.cgi?id=900173. Mind adding a comment there with some more information about what you are seeing and your font settings? I can take another look at it.

      February 13th, 2014 at 13:01

    2. Brian Grinstead

      You can close the object inspector in the console with escape, but it could definitely be more obvious.

      Regarding the object literal output not coming as expected, I’ve filed https://bugzilla.mozilla.org/show_bug.cgi?id=972530.

      For the vim keybindings causing side effects, I’ve filed: https://bugzilla.mozilla.org/show_bug.cgi?id=972534

      February 13th, 2014 at 13:16

  16. Tiago Celestino

    I’m come back the Firefox :)

    February 15th, 2014 at 08:23

  17. Tanima

    Very glad to see your impressive progress with Mozilla development tools. Sometimes i face some problems that i can not browse all sites. It shows like browser can not loading this. I can not understand this problem.

    February 16th, 2014 at 04:10

  18. Tanima

    Here i face with same problem that any chance of implementing https://bugzilla.mozilla.org/show_bug.cgi?id=962491 (or something similar) at some point? It would make debugging CSS added by JS events so much easier.

    February 16th, 2014 at 04:13

  19. Hochzeitsfotograf

    Thank you for the tip with the different Versions of Firefox! Great!

    February 19th, 2014 at 12:46

  20. Cezary Tomczyk

    Is there a plan to implement “events” for debugger? Currently there is no way to see what type of events are attached to specified DOM element.

    February 24th, 2014 at 13:31

    1. Brian Grinstead

      If I understand correctly, this is being worked on in the markup view: https://bugzilla.mozilla.org/show_bug.cgi?id=736078. The WIP looks something like this: http://i.imgur.com/VZcbCX1.png.

      February 24th, 2014 at 13:36

      1. Cezary Tomczyk

        Hm, 2 years and status “ASSIGNED” with priority P3 :-( I was thinking that this would be P1 since most developers playing with events every day.

        BTW Personally I think that there is too many colors there. Just distracting. Maybe when this blue and grey background on event name when will be removed then it would be better.

        February 24th, 2014 at 13:52

  21. Jose

    Good work and visually stunning. Still behind Firebug in some features like DOM properties exploration and debugging of dynamically loaded JavaScript files which are absolutely necessary in complex web apps but it’s advancing at good pace and with style ;)

    February 27th, 2014 at 10:33

Comments are closed for this article.