Firefox Developer Tools and Firebug
hacks.mozilla.org
hacks.mozilla.org
However, they were worried about the codebase becoming too big -- after all, 99.9% of people wouldn't need a DOM inspector. So, the add-ons architecture was born. Firebug was created as a separate tool by Joe Hewitt. Add-ons and Firebug probably ended up being the reason why Firefox took off.
Opera had little miniature windows inside the main window. A small difference, perhaps, but tabs are simpler to manipulate at the cost of, perhaps, being less flexible (you can't resize tabs and move them around like you can windows).
So I would love to be able to use the developer tools - but for me they're still not quite there (but getting close). Here's some things Id like to see, and then I think I could change over from chromes devtools completely, wonder what other devs think?
1. speed (becoming less of a problem)
2. edit html in elements inspector, also dynamically creating styles: - What I like about chromes devtools is the fact that I can completly alter my html page via the elements panel (styles and html) very fast, also auto-expanding to the selected element and seeing its surroundings is nice.
3. network panel still not as good as chromes (imho) - mainly because I cant enlarge the detailed inspection of each listed http request.
4. too intrusive (popups for javascript editor) - make it more compact and use less space, also I like tabs (that are optionally detachable) instead of windows.
And thats it, these are the only reasons for me personally, why I dont use firefox as my development browser of choice.
But again Id like to say the work the mozilla devteam is putting into the devtools makes me think its just a matter of time until I can finally go back to mozilla :)
2) You can do this already. It works just about the same as chrome dev tools, create a new rule to add a new css rule, etc.
3) I would like this too.
Note, when I say style here, I mean style on the HTML tab, not the style tab itself.
You can edit all of the individual components of a tag (attributes, the tag itself, add new attributes, etc.), but you can't edit/select the entire tag or child tags at once as you can in Firebug.
This can be really powerful, because when you can edit an entire tag including the open/close brackets, you can type in whole new tags or paste in a blob of new HTML.
This bug was the closest I could find: https://bugzilla.mozilla.org/show_bug.cgi?id=777009
2. +1 for the above mentioned network panel details, I agree, and the URL of the request can not be copied currerntly, that's mean :)
3. +1 for the need of stacktrace, like in chrome, that's sooo needed
4. A shortcut in it's settings for disabling the cache
(If you substitute the native dev tools in this thought experiment with Brackets or Sublime Web Inspector, you start to see the power of decoupling tooling from the browser.)
Our RDP (Remote Debugging Protocol) is not interoperable with the one in Chrome or any other browser. There are two reasons:
1) Both us and Chrome team would like to iterate on our protocols and tools as fast as we can. Maybe in future, when tools across browsers stabilize there will be a case for a standard but I personally believe that a wrapper protocol is a better answer.
2) RDPs depend on their platform's architecture. Ours is very SpiderMonkey centric while Chrome's is all about V8.
Google organized a nice Summit during the I/O this year and I attended on behalf of our team (video: https://www.youtube.com/watch?v=SOO9Kb1-JJU). I shared my thoughts on interoperability and other issues here: https://medium.com/web-developer-tools/1060a9f69e6a
Hope that helps.
The Google Web Toolkit team was looking at this; instead of their historical approach of using a JVM to run/debug user code (because that was actually a really great idea in IE6), using the native JS debuggers in FF/Chrome/etc.
...except that there is all sorts of wonkiness, like only 1 debugger is supported at a time, so you can't use, say, Eclipse (whether for GWT or pure JS debugging) + FF dev tools for inspecting CSS/etc. at the same time. And you can only connect to 1 tab...something, something. I was not directly involved, but it didn't sound pleasant.
Anyway, I totally agree that native dev tools should be decoupled/play friendly with other tools.
AFAICT, so far the FF/Chrome engineers are going down the path of basically building IDEs from scratch, in the browser itself.
Which was great for Firebug, and inspecting elements, but for a debugger, I really want to stay in my IDE.
It's more like Mozilla cannibalizing itself, than anything else.
[1]http://www.chromestory.com/2011/07/firebug-guru-joins-chrome...
The integrated tool are getting better but I often forget they're there. The responsive page resizer/viewer I use frequently
Tools->web developer seems to incorporate firebug and the native tools (confusing...). I like the way firebug puts a little button on the menu bar I can click to turn debuggin on and off.
We'll see how this shakes out.
However, I mainly use FB to inspect network requests nowadays and if you do a lot of Ajax calls, inspecting the responses and the json could require less clicks IMHO.
I've seen not-terribly technical people— or at least people who'd never otherwise have firebug installed— go and edit braindamaged forms to get a webpage working right. Having it built in is practically empowering.
Not anymore, judging by binary size and lines of code.
And as a slight nitpick, the IE Dev toolbar came out about 6 months before Firebug and as best I can remember actually had more functionality than Firebug for quite a while.
It's some sort of persistent web developer myth that Firebug came first. Firebug was just easier to find/install, you had to know that the IE6 developer toolbar existed.
NB: I hate IE as much as the next web dev, but credit where credit's due...
If you find this isn't happening for you, please file a bug: https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&c...
> We thought long and hard about including Firebug wholesale and considered several approaches to integrating it. An early prototype of the Inspector even included a significant portion of Firebug. Ultimately, integration proved to be too challenging and would have required rewrites that would have been equivalent to starting over.
Regarding Fx dev tools, they e.g. do not show evaled scripts at all in the JS panel. Also I don't see a way (yet) to have debugger and console visible at the same time. And there are many other tiny Firebug goodies not implemented yet here and there. Firebug will be still essential for me for many months.
I suppose, in the near future, some redundant features will be cut from Firebug.
I hope Firefox Dev tools clone the best parts of Firebug and Chrome Tool.
What I'd really like, though is a single set of web devtools that can inspect any browser. Having to learn a different set of devtools for each browser is a pain when you have to test a slew of different browsers.
It's a pipe dream, but I filed a bug anyhow: https://bugzilla.mozilla.org/show_bug.cgi?id=924670
Please add support, reason why: http://stackoverflow.com/questions/2669690/why-does-google-p...
I don't understand why they did not just integrate Firebug directly. What were the reasons?
> An early prototype of the Inspector even included a significant portion of Firebug. Ultimately, integration proved to be too challenging and would have required rewrites that would have been equivalent to starting over.
Specially when their feature set starts to overlap.
For me it seems all very political.
"Google only supports the most current dev, beta, and stable channel releases."
Given the frequency of the stable channel releases, I'd rather go for the Firefox ESR version.