The last time I used Firefox (when Australis moved from Nightly to Aurora) the inspector still lacked the completely-necessary function of adding/creating new rules and classes to a stylesheet. Chrome DevTools have a little "+" that lets you write in an entirely new selector or rule without having to edit an existing one. Does Firefox's native inspector have this feature yet? If so, I can't find it... and it's a gaping hole in their tools. One that keeps me on Chrome, unfortunately.
Break on attribute or subtree modification
HTML Node drag and drop (yup! Chrome DevTools have it)
XPath (I use it for testing)
FPS monitor and force repaint
Thanks for the info. What are you wanting to do with xpath? The console supports the $x function, like $x("//body"). Also, HTML node drag and drop is on the radar here: https://bugzilla.mozilla.org/show_bug.cgi?id=858038
I want to get XPath from a node. I use it in WebDriverJS.
Good to see drag and drop coming.
There was some features that I loved. It's not fair to not mention those:
CSS autocomplete is much better than Chrome’s
Code Editor’s Search is just amazing!
The filter for computed CSS properties is very handy for my work
Black Theme is great! Please make it easy to write custom themes
One little request, in console. ⌘+K should clean the console.
That seems to be premature. Depends what you consider a DevTool. Chrome still has far better profiling/tracing tools for performance analysis. The latest Chrome versions even let you hover over functions and view what the V8 JIT thought of them (e.g. deoptimized and why). Even relatively low hanging fruit, like debugging WebWorkers is missing from FF. I see tons of missing stuff that Chrome DevTools has that FF is missing. It doesn't have something like the Timeline tab for tracking memory/framerate over time. I don't see stuff like HTML5 FileSystem/IndexDB/localStorage browsing. SourceMap support doesn't match Chrome. Etc.
FF seems to do better with the DOM/Designer portion of tooling, but from a JS-heavy coder perspective it seems behind.
Sometimes I wonder if Chrome and Mozilla could standardize on some DevTool APIs, like JVMs standardized on JVMTI/JPDA, so that a portion of the code could be shared and people could build JS dev-tooling that would work with either browser.
Obviously, there's lots of stuff that is tied to internals, especially when it comes to profiling and native code bindings, but it seems like something could be done.
A good start would be for JS VMs to adopt a standard debugger protocol so that attaching a tool to the JS debugger would be browser independent.
You mean catch up to where DevTools are right now, by the end of the year? Firefox's tools have been behind Chrome's for years, I really don't see how Chrome's will "fall behind". You know Chrome has people working on it too, right?
As a GWT maintainer I would be overjoyed if Firefox would simply match Chrome as a solid, fast JavaScript debugger that supports sourcemaps well for large apps. The announced bells and whistles aren't going to help my users if they can't even debug their code.
Interesting they've added option to hide buttons, but kept huge icons on tabs, chrome used to have similar ugly icons, but fortunately they are removed now.
Live editing JS and recompile doesn't seem to be possible from devtools. My experience with scratchpad doesn't do that so I have to fall back to Chrome when I want to edit JS loaded by the page on a third-party site. Is that still true?
As far as full live editing goes, we have some refactoring and infrastructure work that needs to happen first that also blocks things like properly debugging eval'd strings and dynamically appended scripts. Its pretty high on our priority list and should be coming soonish!
I love all the work the Firefox team is doing here over the last year. Things have improved so much, its terrific. These are the things Firefox needs before I could start to consider it as a primary development tool:
- Performance analyzation
- Resource management (cookies, local storage, etc)
- Option to completely disable cache when dev tools are open
Edit: I can't find it. I see I can disable the cache completely, but that's not really what I want. Its nice to only disable it when the dev tools are open. I don't want to have to go to advance settings and clear it every time.
This is how Chrome DevTools do it (by default), and it's incredibly useful. When I'm just browsing websites I want the cache enabled, but when I'm working on a site (in which case I usually have the DevTools opened) I want the cache disabled. In fact, I now just open the DevTools when I want to temporarily disable caching -- because the keyboard shortcut is so ingrained it's a lot easier to do that then find the overall browser setting itself.
I know that's how Chrome DevTools does it, but "because that's how Chrome DevTools does it" is not a good answer to the question "why specifically when the DevTools are open".
Because you don't want to disable caching of every other sites when you are not wearing your developer hat, just a "regular user surfing internet" hat.
This is exactly the point -- when you're developing a site, you want caching disabled on that site, but then when you're browsing another site just as a regular surfer you do not want caching disabled. Since generally when you're working on a site, you have DevTools opened, and generally when you're just browsing the web you do not have DevTools open, this is very nice.
"How Chrome DevTools does it" was not my answer to the question, it was just the preamble. As mentioned, I much prefer to have caching disabled while I'm building or debugging sites (specifically: because I'm often changing the markup or the css or the javascript, and I want my most recent change to come through to the browser upon reload).
Disabling the cache by default can be troublesome. I'd say it breaks the principle of least surprise - I wasn't aware of this behavior in Chrome, and it's a good thing I develop with Firefox, as I just resolved a bug that only manifested itself when bypassing the browser cache. If the browser cache had been linked to dev tools being open in my case, I probably would have ended up down some false causality rathole around dev tools.
We implemented it that way so that we wouldn't have a never ending list of "the browser is slow when devtools are open" bugs.
We do plan on making the disable cache toggle more visible (probably with the other buttons at the top of the main panel) and making it very obvious that the cache is disabled.
When we have done that it would make sense to have the button remember state.
I'm actually surprised developers using Firefox don't use firebug? It's great that Mozilla are improving the native tools but they are a long way from a moving goal post that is Firebug.
I love the look of the font preview. One of my major gripes with web fonts and listing multiple sources is not knowing which font rule is actually applying. Looks like this might solve my problem.
I wish I could get a reference from the console command line to an object I printed in the console earlier.
For example: in my code I write console.log({ foo: function(msg) {...} }). The object is displayed as "[object Object]" (which isn't as good as Chrome's output by the way) and, sure, I can click it to inspect it,but what I'd like is, like, right-click->"Copy reference" and then it puts "$_(123)" in my clipboard, where $_ is a console-defined function which takes a number and returns the matching output of the console history.
Then I can use the referenced object in a new command: e.g. $_(123).foo('hello').
Firebug has $_ [1] but it's just for the last output of the command line (not the console history). (edit: likewise for Chrome [2])
The box model highlighter looks great. This was the only reason keeping me from switching from firebug to dev tools entirely. Also, the other improvements are great news as well. Good job!
53 comments
[ 8.9 ms ] story [ 965 ms ] threadI would love for there to be some node.js plugin where I could basically connect to the browser's js console.
Today it's not possible for me to make the switch. There are some features that Firefox devtools is lacking from DevTools.
Good to see drag and drop coming.
There was some features that I loved. It's not fair to not mention those:
One little request, in console. ⌘+K should clean the console.This is a bitter pill: any shortcut we choose is a different kind of 'wrong'.
https://addons.mozilla.org/en-US/firefox/addon/xpath-checker...
It's open source, so perhaps you could reuse the code from WebDriver:
https://code.google.com/p/xpathchecker/
FF seems to do better with the DOM/Designer portion of tooling, but from a JS-heavy coder perspective it seems behind.
Obviously, there's lots of stuff that is tied to internals, especially when it comes to profiling and native code bindings, but it seems like something could be done.
A good start would be for JS VMs to adopt a standard debugger protocol so that attaching a tool to the JS debugger would be browser independent.
https://bugzilla.mozilla.org/show_bug.cgi?id=704252
As far as full live editing goes, we have some refactoring and infrastructure work that needs to happen first that also blocks things like properly debugging eval'd strings and dynamically appended scripts. Its pretty high on our priority list and should be coming soonish!
- Performance analyzation
- Resource management (cookies, local storage, etc)
- Option to completely disable cache when dev tools are open
- Ability to search the document in the inspector
I'm sure they'll get there before too long.
Edit: I can't find it. I see I can disable the cache completely, but that's not really what I want. Its nice to only disable it when the dev tools are open. I don't want to have to go to advance settings and clear it every time.
> when you're developing a site, you want caching disabled on that site
I don't know why you say that. I only want caching disabled if I'm debugging something I think might be caused by caching.
We do plan on making the disable cache toggle more visible (probably with the other buttons at the top of the main panel) and making it very obvious that the cache is disabled.
When we have done that it would make sense to have the button remember state.
For example: in my code I write console.log({ foo: function(msg) {...} }). The object is displayed as "[object Object]" (which isn't as good as Chrome's output by the way) and, sure, I can click it to inspect it,but what I'd like is, like, right-click->"Copy reference" and then it puts "$_(123)" in my clipboard, where $_ is a console-defined function which takes a number and returns the matching output of the console history.
Then I can use the referenced object in a new command: e.g. $_(123).foo('hello').
Firebug has $_ [1] but it's just for the last output of the command line (not the console history). (edit: likewise for Chrome [2])
Thank you for the many enhancements.
[1]: https://getfirebug.com/wiki/index.php/Command_Line_API#.24
[2]: https://developers.google.com/chrome-developer-tools/docs/co...