New Performance Tools in Firefox Developer Edition 40

https://hacks.mozilla.org/2015/06/new-performance-tools-in-firefox-developer-edition-40

by _jomo • 11 years ago

182 46 11 years ago

hacks.mozilla.org

EdSharkey7• 11 years ago

Now I don't need to jump into Chrome to do my frame rate tuning, I just need to shut off Firebug and plop over into Developer Tools! Huzzay!

chimeracoder• 11 years ago

Out of curiosity, what do you use Firebug for that the regular developer tools can't handle?

There used to be a huge feature gap between them, but that's been shrinking for a while, and I thought it had been eliminated altogether.

pmontra3• 11 years ago

Firebug still has a better UI. The dev tools seem coming straight from the 90s (Chrome's ones too) but they feel faster. Advantages and disadvantages in functionality are mixed, but I end up using Firebug almost all the time. Unfortunaly I'm on a tablet now, if I were at the computer I'd give you examples. I wish the teams merge and give us dev tools with a Firebug UI and all the functionalities of the two tools.

EdSharkey7• 11 years ago

I have seen this question a lot when Firebug vs. Developer Tools comes up ... for like years and years, since Developer Tools first dropped even. Now you've got me curious. Please reply with points I offer below that you HAVEN'T heard before.

1. Just make Find work right. I need global find, that's all I need. On what corporate drone planet is it a smart idea to prepend an exclamation mark to search terms to request a global find? Chrome makes the same mistake - The Search Company got Find wrong... (Perhaps Chrome ain't all that and a bag of chips!?)

MAKE CTRL-F DEFAULT TO GLOBAL FIND! [Scream your favorite cuss word now if you're with me on this!] One strike and you're out when you screw up something dead simple like Find!

I don't need file-catalogged search results where I stoke my chin and ponder all the matches; just go to each match by jumping around directly in the source, let me hold down Enter while you cycle through the matches and source files, let me know when we wrap around the search result list with a little informative "search results wrapped" pop-under - how do I describe my frustration?? FIND IS VERY UNPRODUCTIVE AND OVER-ENGINEERED IN DEVELOPER TOOLS. This is somebody's baby, I'm sorry to whomever if he is reading this - I just think simple is the key and that's what Firebug has going for it. Just do me a favor and toss the whole Find as you got it into an Advanced Find dialog box and give me simple, Firebug-style, rip n' roll global find in Developer Tools, PLEASE.

2. I know Firebug is an opt-in extension, so they have the right to do this, but ... Firebug puts that handy bug icon on the location bar for popping open the firebug panel. It's nice, appeals to my lazy muscle memory! I'm sure the Firefox Developer Edition does something similar (right??), and they wouldn't force me to go rummage the hamburger menu for their link in that version of Firefox. But, I'm too unmotivated to switch to that version of Firefox. I'm far too unmotivated to customize my location bar (except to remove the new Pocket icon, gross.) The firebug icon is beautiful, I want to click its button.

3. I like the tabs in firebug better than those in developer tools. The CSS inspector is great in Firebug, always has been very productive.

4. Breakpoints are hinky in Firefox in general, both in Firebug and in Developer tools. I've seen the JIT'er optimize away my line with a breakpoint in both environments, but in Firebug my breakpoints seem to 'catch' a little better.

I'd like to see a lot more work done on breakpoints in the debugger in general and have breakpoints (potentially) survive refreshes (or Webpack autoreloads) where the sources or script filenames have have changed. I suppose the debugger could achieve this linking my breakpoints to line numbers in sourcemaps rather than to the .js files themselves. If it already works this way, then I must be doing something wrong, because I am constantly losing my breakpoints when actively developing code that I am also stepping through.

5. Could we just have the Firebug UI atop the Developer Tools? Firebug has made Firefox unstable lately leading to stalls and shutdown timeouts. I would love to see Firebug team re-skin the developer tools with their UI and throw away the firebug kernel. The native integrations in developer tools are bound to do a much better job debugging than an extension like Firebug ever could. I thought I heard that this was the plan for Firebug.next, and I am all for it.

acemarke• 11 years ago

Disclaimer: I'm still stuck on FF31 for dev testing purposes (internal application targeting FF31 ESR), and haven't tried newer builds.

My biggest complaint about both Firebug and the FF Dev Tools is the way they list downloaded content files. FF Dev Tools seems to only have a flat list of filenames, which is ridiculous. Firebug has a dropdown that can be filtered by name, which helps, but is slow.

I'd always been a Firebug user, but I finally gave Chrome Dev Tools a shot a few months back and was sold by a combination of its speed and general usability. In this case, stuff like having an actual tree of content files that I can expand.

Also, to echo another comment, Firebug seems to go haywire every so often while trying to set breakpoints. Either the breakpoint symbol just spins and never actually sets, or when you reload the page it acts like you set the breakpoint on the last line of a module, etc.

Haven't yet tried out Firebug 3, as it requires FF35+.

Touche• 11 years ago

Firefox Devtools still shows scripts in the debugger as one single scrollable list. No folder hierarchy.

thousande• 11 years ago

The next generation Firebug will be built on top of the native dev tools, https://blog.getfirebug.com/2014/11/10/firebug-3-next-genera...

ohitsdom• 11 years ago

Seems like the Performance Tools is now on par with Chrome, unless I'm missing something. These tools are sorely needed for web developers, Nik Molnar's talk[0] on web performance is a great intro on how to use these in real world scenarios.

[0] https://vimeo.com/97415381

callahad3• 11 years ago

Memory profiling is a big missing piece, but it's in Nightly right now, and should show up in DevEdition 41 or 42 :)

mistermann2• 11 years ago

Will this at all help to help diagnose and maybe even fix why FF eats so much memory? I keep getting out of memory errors in windows and see FF eating tons of RAM & Virtual, and have no idea which is causing the errors or how to fix it.

mrinterweb• 11 years ago

These tools look fantastic. Off topic: the first video showed the use of the new tools and the improvements of using a web worker. I was reminded of how little I like the implementation of web workers in regard to needing to call out to an external script. The implementation would have been much better if it was possible to treat scripts in the same file as threads. I have seen hacks/workarounds to toString() functions and inject them into the DOM, but it is unfortunate that this is required for inline web worker use.

eterm3• 11 years ago

Finally my test page[1] no longer crashes my browser with the dev tools open, and appears to run the same speed with and without the dev tools open. I don't know if it's related to these changes but clearly it could be.

[1] http://rcocks.github.io

Edit: Actually it seems to not happen if I don't go to the "inspector" tab but go straight to the performance tab. Ah well, shame there seems to be a lingering issue but I'm happy that I have a workaround now anyway. (It used to crash hard on the performance tab too.)

dblohm72• 11 years ago

Please report this!

eterm3• 11 years ago

Don't worry, it has been previously reported at bug#1123322 [1]. I've updated it to note my latest findings.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1125322

malkia• 11 years ago

You are also measuring parseFloat(hdn.value) - but I haven't measured how much of impact it is.

EDIT - Turns out it takes significant amount of time compared to the rest of the frame, more on chrome, a bit less on Firefox (but the timing profiles are very different on the two browsers).

parsing floats is not fast! :) (Many edge cases)

eterm3• 11 years ago

Oh I know! I realised that later on when I reviewed the code but I gave up worrying about demonstrating the speed of DOM access* when it started to crash my browser! So I've left this version here for posterity.

* I wanted to demo to some people why it's better to write javascript that avoids going back and forth to the DOM all the time.

acomjean• 11 years ago

I like the firefox tools and use them a lot. They kept getting better and better but recently seem to have plateaued. I keep running into things on ocation that make me switch to chrome to debug. I sound a little cranky and ungrateful, but the firefox dev tools are good and I like the way they're set up, but when I can't get my breakpoint to stop javascript execution and I have to switch browsers I get a little sad.

Looking quickly the developer edition seems to fix some other little things (the return of Labeling margin, padding, border on the box model and the ability to edit the box model in place).

I'm always a little leery of special editions as it was good to develop on the browser your deploying to.

callahad3• 11 years ago

Developer Edition is a pre-beta version of Firefox (the core code goes from Nightly -> DevEdition -> Beta -> Release, much like Chrome goes from Canary -> Dev -> Beta -> Stable). DevEdition also ships with some more minor customizations to ease development: a separate default profile, buttons in the toolbar for the Developer Tools, etc.

The plateau you're referring to is probably due to the team's focus this quarter on building the all new performance tool, making sure all the tools work with process separation (e10s), and trying to squash bugs around polish and stability. The next few quarters will likely see a return to pushing on user-visible features.

We also have an opening for a full-time interaction designer on the DevTools team. If you dig this stuff, or know someone who does, please consider applying at https://careers.mozilla.org/en-US/position/oLiW0fwJ

CWuestefeld• 11 years ago

Is it possible to have side-by-side installs of the current stable release as well as developer edition?

phs2501• 11 years ago

Do you have a timeline for getting proper (source-mapped) file/line numbers in the console (and performance tools, I just checked and it's absent from there as well)? This is currently the main reason I reach for Chrome when I need to write JavaScript. I see this bug marked devedition-40:

https://bugzilla.mozilla.org/show_bug.cgi?id=670002

but I still see "bundle.js:23796" in my console in Dev Edition 40, which is less than useful.

gsam• 11 years ago

40

Triple digit version numbers are just going to sound ridiculous. I really hope someone reigns this back in at some point.

I'm keen to test some of these new features out though. The tools in Firefox have always been a bit hit and miss for me and I've actually never went out of my way to use Chrome or Firebug.

petval• 11 years ago

Will it finally enable us to find an offending tab that is consuming too much memory or CPU? Or it's just a tool that can be used to build this functionality? Something like Opera 12 has in opera:cpu.

jacobolus• 11 years ago

I’d love to have some end-user control to throttle tabs’ CPU/memory. In particular, if I have a background tab open that I haven’t brought to the front in a few hours (or longer), I pretty much don’t want it to get any CPU cycles at all until I explicitly look at it again, and usually I also want to have its open TCP connections closed, etc.

New Performance Tools in Firefox Developer Edition 40

Related Stories