New Performance Tools in Firefox Developer Edition 40
hacks.mozilla.org
hacks.mozilla.org
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.
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
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.
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.)
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)
* 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.
Unless you have lots of content open that inherently uses a lot of memory, or something.
From sysinternals process explorer I see working set 1.6GB and Virtual Size 2.6GB with ~200 tabs open. Don't understand why the virtual is so big.
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.
When debugging in Chrome/IE it's always painful to use the developer tools even though they are very capable.
Inspector, HTML editing, Net panel: Basically the same.
Storage: you can inspect localstorage and IndexedDB with dev tools. You need https://addons.mozilla.org/en-US/firefox/addon/firestorage-p... for inspecting localstorage with Firebug. No IndexedDB support, but I never used it (localstorage is so much simpler) so I didn't search much. Firebug can delete cookies (maybe that's another extension, can't remember), dev tools can. It could be even, depending on what you use most.
Console: dev tools autocompletes functions. Inspection of variables is abot the same but Firebug displays more information without having to browse all the values tree. Firebug's console is multiline which is handy for typing in short scripts. However that means that commands run only with CTRL-Enter. I prefer Firebug.
HTML structure: the same but the dev tools bury the DOM tab into a right click menu. I prefer Firebug's UI.
CSS editing: the same.
Script/Debugger: almost the same but I prefer Firebug because of the way it displays information about the variables (similar to my reasoning about Console).
Aesthetics: Chrome and Firefox dev tools looks more primitive than Firebug to me but this is very subjective and I have a theory about it. Web and mobile have been moving to a minimalistic and flat design for the last few years. Having used computers since the 80s that reminds me of some designs of the 80s/early 90s. The flat Windows 8 desktop mode decorations are somewhat similar to the early Windows (check http://www.webdesignerdepot.com/2009/03/operating-system-int...) with obviously everything that more pixels, colors and animations allow. Still I can't feel it a bit deja-vu like some elements of fashion that came back after forty years (example: the brown color - Europe here, USA could be different). Younger folks will say that are Firebug's 3D buttons to look dated and I understand it. But just wait some 20 years and I bet you'll start having that feeling too :-) As I said: very subjective.
Summary: that basic functionality is more or less the same and the difference is probably more a matter of UI and habits than of technical merit. There might be some use cases where you need to dig into dev tools' options and enable more functionality. Dev tools win there.
Like with most similar consoles the Firefox dev tools allow you to create newlines with Shift+Enter
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.
If I press Fn+F12, Firebug opens, though. ;)
Ed: you should try ( and provide feedback to ) Firebug 3, they're dong exactly what you described - implementing Firebug UX on top of Firefox Devtools:
1. Having a dropdown for sources in the Scripts pane is unwieldy/useless for large sites with tens of different scripts. The Developer Tools get this most right by having a docked Sources/Call Stack navigation panel to the left of the source.
2. Inspecting a JS Object's value in the Watch panel pops over to the DOM tab to view it there. I've always thought that tab was oddly named and that made the transition confusing since I'm often not looking at DOM objects there. I think that tab should be named "Object" or "Object Viewer".
3. Web Worker threads and breakpoint support
4. Web Sockets and WebRTC debugging tools
I try to TDD my code (or at least write lots of tests to dig myself out of the hole), so I don't find myself doing heavy breakpoint debugging as much these days.
https://hacks.mozilla.org/2013/03/firefox-developer-tools-wo...
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+.
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.