Firebug lives on in Firefox DevTools(hacks.mozilla.org)
hacks.mozilla.org
Firebug lives on in Firefox DevTools
https://hacks.mozilla.org/2016/12/firebug-lives-on-in-firefox-devtools/
124 comments
I positively adore Firebug, with the DOM panel alone being worth its weight in gold.
As far as our new environment: The scratchpad seems like a neat tool for larger code 'experiments', but to it's placement in the overall tools is puzzling. The Scratchpad and Console should be combined without needing to enable "Toggle split console", at least for bottom docking.
Firebug brilliantly combined these two to form the ultimate JavaScript REPL, doing so in the way that maximized available screen space (side by side). To replicate the same functionality the new system requires two space wasting windows spanning the entire width of the browser.
Also, and am I crazy here: but one of the commands to run code in the Scratchpad is Command-R. That just refreshes the entire page, which would appear to make it the worse short-cut in the history of modern software. The one shortcut to run code that does seem to work, Command-I, is incredibly inconvenient to type. Yes we have buttons, but shortcuts are nice too.
Overall though: Firebug was and has been a revelation. It's empowered me to write better code in less time, and I'm pleased to see it live on.
As far as our new environment: The scratchpad seems like a neat tool for larger code 'experiments', but to it's placement in the overall tools is puzzling. The Scratchpad and Console should be combined without needing to enable "Toggle split console", at least for bottom docking.
Firebug brilliantly combined these two to form the ultimate JavaScript REPL, doing so in the way that maximized available screen space (side by side). To replicate the same functionality the new system requires two space wasting windows spanning the entire width of the browser.
Also, and am I crazy here: but one of the commands to run code in the Scratchpad is Command-R. That just refreshes the entire page, which would appear to make it the worse short-cut in the history of modern software. The one shortcut to run code that does seem to work, Command-I, is incredibly inconvenient to type. Yes we have buttons, but shortcuts are nice too.
Overall though: Firebug was and has been a revelation. It's empowered me to write better code in less time, and I'm pleased to see it live on.
I've been using Chrome's dev tools for quite a while now. Can you tell me if Firebug or Firefox' dev tools have any features that I'm missing out on?
I've been using the new firefox developer edition. Pretty nice, although I should probably figure out how to theme it because the default bugs me.
The only problem is about once per day it gets really sluggish and I have to shut it down because nothing is working - after I restart it updates with the latest build. Seems like a connection there. :)
The only problem is about once per day it gets really sluggish and I have to shut it down because nothing is working - after I restart it updates with the latest build. Seems like a connection there. :)
It was that way for a long time for me. My computer would just get shut down for 5 minutes every day, until that dreaded "Update Ready" icon would show up. It's a bummer to hear they haven't fixed it, but it is less noticeable on a newer machine.
Interesting. I run into the same problem with Chrome, usually when I have my dev tools open for significant time.
Firebug was so good, probably one of my favorite tools I've ever used. I would say the current-day Chrome tools surpass it, but the rest are very difficult to use despite them all having gone through several iterations of design.
Chrome's dev tools preserve the "spirit" of what it was like to use Firebug. Others just seemingly put info and stuff in random places, nothing where you'd expect. Why must they be so... difficult? I mean we already had the basic ideas of how these tools should work figured out years ago. Just frustrating. Maybe other devs enjoy using the FF and Safari tools, I certainly don't. I haven't tried any of the recent generations of IE.
Chrome's dev tools preserve the "spirit" of what it was like to use Firebug. Others just seemingly put info and stuff in random places, nothing where you'd expect. Why must they be so... difficult? I mean we already had the basic ideas of how these tools should work figured out years ago. Just frustrating. Maybe other devs enjoy using the FF and Safari tools, I certainly don't. I haven't tried any of the recent generations of IE.
I hate the built in one
one word - sad !
I switched from Firebug to DevTools one and a half years ago and - while I have huge respect to the innovations that came from Firebug's ideas - I'm not looking back as the native devtools have more features these days and a better UI in my option.
So thanks to the dev team and the volunteers picking up my and others bug reports at http://firefox-dev.tools/ (I just leave this to the crowd here on HN ;)
So thanks to the dev team and the volunteers picking up my and others bug reports at http://firefox-dev.tools/ (I just leave this to the crowd here on HN ;)
Me too, I moved to devtools about a year ago.
I was particularly happy with the Cause column in the network tab that tells me why a particular thing was loaded, which line of javascript or which HTML element triggered it. I think Chrome has had that for a while, but it's pretty recent in Firefox. It's one of those little things that make me happy.
I was particularly happy with the Cause column in the network tab that tells me why a particular thing was loaded, which line of javascript or which HTML element triggered it. I think Chrome has had that for a while, but it's pretty recent in Firefox. It's one of those little things that make me happy.
I switched to the builtin tools even earlier, and haven't looked back. Honestly, I thought Firebug merged with Firefox a long time ago, since they both did what I needed, in almost identical ways.
>Honestly, I thought Firebug merged with Firefox a long time ago, since they both did what I needed, in almost identical ways.
Me too. I seem to recall that back when the Firefox inspector and friends first launched they stated that it would be able to do everything that Firebug did, and that the people who had been working on Firebug were going to join Mozilla to work on Firefox instead. I switched from Firebug to the builtin tools soon after it was released.
Speaking of the builtin tools, I found an old announcement about the Page Inspector 3D View [1] which I recently wondered what happened to since it disappeared not long after it was introduced. Apparently it's available as an addon instead now so you can still have it [2] [3].
[1]: https://blog.mozilla.org/blog/2012/03/13/firefox-adds-new-de...
[2]: https://blog.mozilla.org/tilt/#availableasanaddon
[3]: https://addons.mozilla.org/en-US/firefox/addon/tilt/
Me too. I seem to recall that back when the Firefox inspector and friends first launched they stated that it would be able to do everything that Firebug did, and that the people who had been working on Firebug were going to join Mozilla to work on Firefox instead. I switched from Firebug to the builtin tools soon after it was released.
Speaking of the builtin tools, I found an old announcement about the Page Inspector 3D View [1] which I recently wondered what happened to since it disappeared not long after it was introduced. Apparently it's available as an addon instead now so you can still have it [2] [3].
[1]: https://blog.mozilla.org/blog/2012/03/13/firefox-adds-new-de...
[2]: https://blog.mozilla.org/tilt/#availableasanaddon
[3]: https://addons.mozilla.org/en-US/firefox/addon/tilt/
> Speaking of the builtin tools, I found an old announcement about the Page Inspector 3D View which I recently wondered what happened to since it disappeared not long after it was introduced. Apparently it's available as an addon instead now so you can still have it
Unfortunately, tilt (or 3D View) does not work with e10s (multiprocess) enabled. There's a bugreport/issue somewhere at bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=937166
https://bugzilla.mozilla.org/show_bug.cgi?id=1114959
Unfortunately, tilt (or 3D View) does not work with e10s (multiprocess) enabled. There's a bugreport/issue somewhere at bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=937166
https://bugzilla.mozilla.org/show_bug.cgi?id=1114959
Based on the title I was expecting a tribute, thanking Firebug for paving the way, so to speak, for the modern DevTools. But this is even better! I know a lot of people preferred Firebug, so hopefully the marriage of it and DevTools will mean good things for them.
I've been using firebug pretty much since it came out. Firebug was an amazing leap forward in web development. I totally understand why its being deprecated but we can all tip our hats for the innovation that it brought. It really can't be understated.
As an aside I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users. Maybe because it's just easier than making them optional extensions? Does anyone know about what year this started?
As an aside I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users. Maybe because it's just easier than making them optional extensions? Does anyone know about what year this started?
>As an aside I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users. Maybe because it's just easier than making them optional extensions? Does anyone know about what year this started?
This is total conjecture but I wouldn't be surprised if it had something to do with competitive advantage. The best browsers to develop for have a better chance to become the browsers of choice because when things were less standardized (or browsers adhered to standards less) webpages could run better in one browser than another (if they even worked in multiple browsers at all). IE kind of breaks that theory but they had other ways to push IE that did not depend on quality or ease of development.
This is total conjecture but I wouldn't be surprised if it had something to do with competitive advantage. The best browsers to develop for have a better chance to become the browsers of choice because when things were less standardized (or browsers adhered to standards less) webpages could run better in one browser than another (if they even worked in multiple browsers at all). IE kind of breaks that theory but they had other ways to push IE that did not depend on quality or ease of development.
Good point, less development friction gets web developers to "sign up" for your browser. Web developers who are using your browser to develop make sites that work well in your browser! This makes perfect sense! I can't believe I didn't think of that.
Personally, I absolutely love that developer tools are included in all browsers. I think its absolutely fantastic, just surprising to me it ended up that way.
Personally, I absolutely love that developer tools are included in all browsers. I think its absolutely fantastic, just surprising to me it ended up that way.
It's basic marketing, appeal to the thought leaders. It's how Google marketed Chrome.
The other vendors were just playing catch-up, especially Microsoft.
Plus it was handy for their own devs and aligned with their strategy (make the web awesome because more web is more Google ads).
The other vendors were just playing catch-up, especially Microsoft.
Plus it was handy for their own devs and aligned with their strategy (make the web awesome because more web is more Google ads).
[deleted]
> Personally, I absolutely love that developer tools are included in all browsers. I think its absolutely fantastic, just surprising to me it ended up that way.
Only one of the browsers I regularly use contains dev tools (Firefox); there are no dev tools built in to w3m, dillo, conkeror or lynx.
There were also no dev tools in eww, w3, konqueror, arora, midori, links, elinks or netsurf last time I used them.
In fact, I've only ever seen dev tools in two browsers, Firefox and Chromium, although my observations are biased since I only use Free Software ;)
Only one of the browsers I regularly use contains dev tools (Firefox); there are no dev tools built in to w3m, dillo, conkeror or lynx.
There were also no dev tools in eww, w3, konqueror, arora, midori, links, elinks or netsurf last time I used them.
In fact, I've only ever seen dev tools in two browsers, Firefox and Chromium, although my observations are biased since I only use Free Software ;)
You sound like a bit of an edge case.
For what? Firefox DevTools? I use Firefox, spent several years as a Web dev, and use FireBug pretty much every day, so I think I'm part of the core demographic. That's unrelated to my use of other browsers though: right tool for the right job, and all that.
The parent just-so-happened to make a tangential comment about "all browsers" bundling dev tools, which I found quite short-sighted. If you're QA testing a commericial Web site then by all means use "all browsers" as a shorthand for "the popular browsers". But if you're commenting on the general development of browsers and their features, such statements need to be qualified. After all, there are some good sibling comments discussing WorldWideWeb, Netscape, etc. Should they be dismissed as "edge cases"?
Maybe instead of listing the software I actually use, I could have taken a guess at how many mobile browsers lack dev tools; I imagine there are many users of such browsers, which is far from an "edge case", although I avoided making such conjectures since I've never browsed the Web on a mobile phone.
The parent just-so-happened to make a tangential comment about "all browsers" bundling dev tools, which I found quite short-sighted. If you're QA testing a commericial Web site then by all means use "all browsers" as a shorthand for "the popular browsers". But if you're commenting on the general development of browsers and their features, such statements need to be qualified. After all, there are some good sibling comments discussing WorldWideWeb, Netscape, etc. Should they be dismissed as "edge cases"?
Maybe instead of listing the software I actually use, I could have taken a guess at how many mobile browsers lack dev tools; I imagine there are many users of such browsers, which is far from an "edge case", although I avoided making such conjectures since I've never browsed the Web on a mobile phone.
Opera, Safari also have dev tools, although those are both webkit-based, these days. IE's had (non-sucky) dev tools since... IE9? 10? Something like that. I'm sure Edge has dev tools.
Part of the issue with a lot of these alternative web browsers is that they don't have fully-fledged JS engines, or WebGL, or a number of other features that web developers like to use to make their sites fancier (and more bloated, etc etc).
Part of the issue with a lot of these alternative web browsers is that they don't have fully-fledged JS engines, or WebGL, or a number of other features that web developers like to use to make their sites fancier (and more bloated, etc etc).
This is interesting; why dev tools are not seen in these FOSS offerings?
Some want to be small and lightweight, e.g. Dillo, so I can imagine them rejecting such features altogether.
Others don't have features like DOM, Javascript, etc. so there's not much they could offer that "view source" doesn't already do.
Others don't have a suitable interaction model, e.g. w3m is effectively a pager for turning HTML into ANSI escape codes; conkeror is keyboard driven so would need a radically different UI for it to be effective; etc.
Others, like Netsurf, Konqueror and the Webkit wrappers (Midori, Arora, etc.) would probably like a dev tools feature, but don't have enough developer power to implement one.
Others don't have features like DOM, Javascript, etc. so there's not much they could offer that "view source" doesn't already do.
Others don't have a suitable interaction model, e.g. w3m is effectively a pager for turning HTML into ANSI escape codes; conkeror is keyboard driven so would need a radically different UI for it to be effective; etc.
Others, like Netsurf, Konqueror and the Webkit wrappers (Midori, Arora, etc.) would probably like a dev tools feature, but don't have enough developer power to implement one.
I'm pretty sure competitive advantage plays a role. Looking at myself and most front-end devs I meet, we tend to use Chrome as a primary browser in part because of the dev tools.
In my case I remember there was a point where I preferred Chrome's dev tools over Firefox' built-in dev tools as well as Firebug, and that played a role in my use of Chrome as a primary browser. Things may have changed, but here I am still using Chrome.
The downside is that I need to remind myself to properly test in Firefox and Safari and, to my shame, it has happened that I entirely forgot and the testing department ended up being that reminder.
Also, Could it be that another reason for dev tools' existence might be that browser developers use it themselves?
In my case I remember there was a point where I preferred Chrome's dev tools over Firefox' built-in dev tools as well as Firebug, and that played a role in my use of Chrome as a primary browser. Things may have changed, but here I am still using Chrome.
The downside is that I need to remind myself to properly test in Firefox and Safari and, to my shame, it has happened that I entirely forgot and the testing department ended up being that reminder.
Also, Could it be that another reason for dev tools' existence might be that browser developers use it themselves?
There might be some truth to this. I use Firefox as my primary browser (despite everyone I talk to from my co-developers to my teenagers expressing shock that I don't use Chrome since "everyone" uses Chrome) because I use Firebug. I've tried using the Chrome developer tools a few times, but I'm so productive in Firebug from long years of use that I just can't get used to it. Maybe now I'll be forced to do so :-(
In Mozilla's case, some of the rationale for including devtools by default is that part of their mission is to make the web accessible to everyone, rather than erect a wall between users and developers (though this does potentially cause some problems). Was Firefox the first browser to make "View Source" a default option in the right-click context menu?
> Was Firefox the first browser to make "View Source" a default option in the right-click context menu?
Not even close. Netscape had this in the late nineties, IIRC.
Not even close. Netscape had this in the late nineties, IIRC.
I don't know which browser first added View Source, but I know it has been there since at least 1995.
[deleted]
This was standard in Netscape 4.x on, if I remember correctly.
You do. It was standard in Netscape & IE 2.
First thing I used, about 30 seconds into viewing my first webpage ever.
No. View Source far predates Firefox, which is relatively new with respect to the history of the web.
The ideal that the Web shouldn't be write-only is not new, either—it's been around around since the birth of the Web; Tim Berners Lee included features to publish pages in the first browser, WorldWideWeb. The idea of built-in devtools in Firefox also isn't new.
Firebug's predecessor DOM Inspector was shipping in Mozilla Application Suite and in Firefox up until Firefox 3. For Firefox 3, the team decided that DOM Inspector's utility to the masses didn't justify its costs. Mozilla Corp was a lot smaller then—150 or so employees. It was a common theme at that time to challenge every part of the browser both because of the QA involved and the ideal of shipping a light, focused product was still something that the team was aiming for. The DOM Inspector code was already mostly self-contained, so it was built and released through addons.mozilla.org as an extension.
The main reason the built-in devtools got included in Firefox aren't so much rooted in user-focused principles as it was convenience for the devtools team. Someone might appear in this thread to dispute this (I half expect Rob Campbell to show up), but it's truer than the idealism line. Bundling the new devtools into Firefox gave two advantages for the people working on it:
1. You're automatically given a big install base, i.e., you don't have to convince people to download your extension.
2. Maintaining features as an extension introduces some work that you don't have to deal with if you just shove your code into the mozilla-central codebase. In 2010, extension authoring sucked. If Gecko couldn't do what you needed or browser.js didn't have hooks for you, you just roll those things into the same patch that introduces (or fixes) the feature you're working on.
Fun fact: The number of years that Firefox has shipped with a built-in inspector actually outnumbers the years that it was without one. Firefox 3 was the first release that didn't include DOM Inspector. That was 2008. A couple years later the devtools project was announced, and it was slotted to ship in Firefox 4—which ended up delayed for 6 months or so. (If I recall correctly, devtools either ended up still missing the boat, or it shipped with parts turned off because they weren't mature/stable enough yet and they were reenabled within the next few releases after Firefox had switched to the rolling release cycle.)
EDIT wrt your comment about no distinction between "developers and users": Firefox Developer Edition's existence is a contradiction
The ideal that the Web shouldn't be write-only is not new, either—it's been around around since the birth of the Web; Tim Berners Lee included features to publish pages in the first browser, WorldWideWeb. The idea of built-in devtools in Firefox also isn't new.
Firebug's predecessor DOM Inspector was shipping in Mozilla Application Suite and in Firefox up until Firefox 3. For Firefox 3, the team decided that DOM Inspector's utility to the masses didn't justify its costs. Mozilla Corp was a lot smaller then—150 or so employees. It was a common theme at that time to challenge every part of the browser both because of the QA involved and the ideal of shipping a light, focused product was still something that the team was aiming for. The DOM Inspector code was already mostly self-contained, so it was built and released through addons.mozilla.org as an extension.
The main reason the built-in devtools got included in Firefox aren't so much rooted in user-focused principles as it was convenience for the devtools team. Someone might appear in this thread to dispute this (I half expect Rob Campbell to show up), but it's truer than the idealism line. Bundling the new devtools into Firefox gave two advantages for the people working on it:
1. You're automatically given a big install base, i.e., you don't have to convince people to download your extension.
2. Maintaining features as an extension introduces some work that you don't have to deal with if you just shove your code into the mozilla-central codebase. In 2010, extension authoring sucked. If Gecko couldn't do what you needed or browser.js didn't have hooks for you, you just roll those things into the same patch that introduces (or fixes) the feature you're working on.
Fun fact: The number of years that Firefox has shipped with a built-in inspector actually outnumbers the years that it was without one. Firefox 3 was the first release that didn't include DOM Inspector. That was 2008. A couple years later the devtools project was announced, and it was slotted to ship in Firefox 4—which ended up delayed for 6 months or so. (If I recall correctly, devtools either ended up still missing the boat, or it shipped with parts turned off because they weren't mature/stable enough yet and they were reenabled within the next few releases after Firefox had switched to the rolling release cycle.)
EDIT wrt your comment about no distinction between "developers and users": Firefox Developer Edition's existence is a contradiction
> Firefox Developer Edition's existence is a contradiction
I'm not involved with Mozilla anymore, but last I heard, there are things you have to use Developer Edition for that can't be done with vanilla releases (like working on add-ons).
Developer Edition enables a number of features not currently available for regular Firefox. The two major ones are build time features which can't be enabled in other releases (besides Nightly). One build feature is Unsigned Add-ons, which allows for add-on development where it isn't possible otherwise. The other is Async JavaScript callstacks which are very useful to capture but tend to slow down regular browsing otherwise. Besides build features there a lot of prefs we turn on to make development easier. If you try using Chrome or Firefox release with DevTools you will need to do something extra to be able to "paste into the console" (something that prevents people on facebook from owning themselves) and that guard isn't on by default in Developer Edition. [I'm the Product Manger for Firefox DevTools]
> Unsigned Add-ons, which allows for add-on development where it isn't possible otherwise
It is possible, you've just chosen to disallow it.
To be clear: the Firefox team took deliberate steps to make sure that add-ons can't be tested or developed in the stock builds of Firefox downloaded from Mozilla.
It is possible, you've just chosen to disallow it.
To be clear: the Firefox team took deliberate steps to make sure that add-ons can't be tested or developed in the stock builds of Firefox downloaded from Mozilla.
Don't think you're right. You can use FDE for add-ons development, just like parent said.
See your sibling below: > Unsigned addons cannot be enabled on beta or release. That was only available for a limited time. Now they can only be enabled on alpha (aka developer), nightly, or special unbranded builds.
See your sibling below: > Unsigned addons cannot be enabled on beta or release. That was only available for a limited time. Now they can only be enabled on alpha (aka developer), nightly, or special unbranded builds.
Please read and understand the entire comment chain you're replying to. I'm well aware that you can use Firefox Developer Edition to develop add-ons. (I'm the one who first mentioned it!)
AFAIK this isn't correct. FDE has some about:config flags set to different defaults than the Stable release, which could mean that a user of Stable might need to flip a switch to allow loading unsigned addons, but there's nothing stopping you from doing so (and addons aren't exactly part of the web platform).
Unsigned addons cannot be enabled on beta or release. That was only available for a limited time. Now they can only be enabled on alpha (aka developer), nightly, or special unbranded builds.
You can make a userscript without any of that hassle, though.
You can make a userscript without any of that hassle, though.
I stand corrected!
It's a long way back for my memory but didn't Netscape Navigator have a WYSIWYG editing mode? That would be at the end of last century.
I think it had. It was later spun put as Composer or something.
[deleted]
> write-only
I think you mean read-only, no?
I think you mean read-only, no?
No
https://en.wikipedia.org/wiki/Write-only_language
in this context it's about having the source code accessible itself, instead of only a binary/bytecode available (or some obfuscated/minified code)
https://en.wikipedia.org/wiki/Write-only_language
in this context it's about having the source code accessible itself, instead of only a binary/bytecode available (or some obfuscated/minified code)
Good response, but as easy as it would be to pretend that this is what I intended all along, intellectual honesty dictates otherwise. Read-only is what I was thinking at the time I wrote it, but I flubbed the words during revision what with all the double negation happening in that sentence. In the world of inspectors on the modern Web, though, the concept of something being write-only is also strongly relevant.
> As an aside I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users.
That percentage is actually pretty close to correct. For that reason and user studies of regular users Edge has already turned off their DevTools by default ( https://blogs.windows.com/msedgedev/2016/11/22/balancing-use... ).
Firefox is currently pursuing moving the DevTools out of the browser and will likely use a similar system to Edge / Safari for activating them. Going the extension route does have complexity drawbacks but being able to ship fixes faster, to a wider audience will be a greater benefit. Additionally as all browsers adopt WebExtensions this could mean that any Firefox panel developed as a WebExtension will be available for use within Chrome or Edge.
That percentage is actually pretty close to correct. For that reason and user studies of regular users Edge has already turned off their DevTools by default ( https://blogs.windows.com/msedgedev/2016/11/22/balancing-use... ).
Firefox is currently pursuing moving the DevTools out of the browser and will likely use a similar system to Edge / Safari for activating them. Going the extension route does have complexity drawbacks but being able to ship fixes faster, to a wider audience will be a greater benefit. Additionally as all browsers adopt WebExtensions this could mean that any Firefox panel developed as a WebExtension will be available for use within Chrome or Edge.
That would be a welcome change. I even say so as a Developer. You can't imagine how often I hit some keys by accident and some DevTools panel turns up - I wonder how that must feel to "normal" users (thinking of my mother here ;)
> I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users.
Not of use to many, but I'm still glad that Chrome includes them - I needed to upload several GB of data the other day, and having both an available web interface and the bandwidth limiting feature in the Dev Tools Network section let me do that upload without impacting other users at the office for the 30-40 minutes that it would have taken when unthrottled.
Not of use to many, but I'm still glad that Chrome includes them - I needed to upload several GB of data the other day, and having both an available web interface and the bandwidth limiting feature in the Dev Tools Network section let me do that upload without impacting other users at the office for the 30-40 minutes that it would have taken when unthrottled.
> As an aside I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users.
I wish this wasn't the case, but I use built-in devtools inspector to work around bad websites that impose invisible ad overlays which are somehow not caught by the combo of uMatrix+uBlockOrigin. I have to use the Inspector to select and delete the overlay so that I can use such sites. Thus DevTools serve a purpose to non-development browser sessions.
I wish this wasn't the case, but I use built-in devtools inspector to work around bad websites that impose invisible ad overlays which are somehow not caught by the combo of uMatrix+uBlockOrigin. I have to use the Inspector to select and delete the overlay so that I can use such sites. Thus DevTools serve a purpose to non-development browser sessions.
Oh yea, for sure, I do the same. I especially modify the DOM to get around "lol, no copying into this form field." That's not really the point I'm trying to make though, 99.9% of users don't have the know-how to do this. You pretty much have to be a web developer to be able to use the browser this way.
I agree, although it helps lower the barrier to entry, so that 99% might become 95% or 90%. More than a few times, I showed people a few simple tricks in the Inspector. They felt empowered and it encouraged some of them to continue digging on their own.
Sure, they could install an addon, but that can be very intimidating if they have never done so. If I "wanted to show them a quick trick", I would have already lost their attention completely by the time the addon is installed.
Sure, they could install an addon, but that can be very intimidating if they have never done so. If I "wanted to show them a quick trick", I would have already lost their attention completely by the time the addon is installed.
Also, let's all be thankful to Joe Hewitt for his work on Firebug and the huge change it brought to web development.
I still use Firebug daily and find it better and easier to use than the Firefox Devtools which in turn is slicker than Chrome Devtools, although the latter enables you to easily develop directly on Android devices connected by USB. I hope they retain the layout and most of the functionality.
It's a pattern to keep in mind. Develop your tools not just for users bot for developers as well, and you'll also have strong engineering ressources targeted at improving your tools and brand.
> As an aside I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users.
AFAIK the firefox devtools team has plans/ideas that the devtools could just used like a normal Web App (loaded from a server). Currently, they are migrating XUL based components over to normal html what would make this possible.
As an example, just like debugger.html which can even be used from any browser in a not-builtin way: https://github.com/devtools-html/debugger.html
AFAIK the firefox devtools team has plans/ideas that the devtools could just used like a normal Web App (loaded from a server). Currently, they are migrating XUL based components over to normal html what would make this possible.
As an example, just like debugger.html which can even be used from any browser in a not-builtin way: https://github.com/devtools-html/debugger.html
Back in the IE 6 days, I used Firebug Lite [0] by adding a script tag in my HTML that would recreate the Firebug interface and most of its capabilities as a panel injected into the page.
[0] https://getfirebug.com/firebuglite
[0] https://getfirebug.com/firebuglite
Yes, in 2017 we'll be shipping DevTools outside of Firefox. At first it will probably be an add-on and we'll evolve from there. But it should mean less time between features and fixes and deliver to developers.
>the firefox devtools team has plans/ideas that the devtools could just used like a normal Web App (loaded from a server)
Someone from the old Opera team must have joined them, no less!
Someone from the old Opera team must have joined them, no less!
I don't understand. Can you elaborate? Have there been previous plan like this by old Opera?
Dragonfly[0], Presto's old dev tools, was essentially a web app (and, IIRC, although cached was loaded as if any other web app), though it had access to some APIs normal websites did not, to be able to communicate with the browser through the Scope protocol[1].
[0]: https://github.com/operasoftware/dragonfly
[1]: https://operasoftware.github.io/scope-interface/
[0]: https://github.com/operasoftware/dragonfly
[1]: https://operasoftware.github.io/scope-interface/
This started with Netscape. They had a fairly awesome built in web page editor. My guess is to make the web and creating web pages an inclusive experience for all users.
This is true but not even close to the same way.
The Netscape had a distribution called Communicator that shipped the browser 'Navigator' alongside a mediocre but serviceable WYSIWYG editor 'Composer'. Other products were included too: an email client, and for a while, a Calendar; the codebase lives on as Mozilla Seamonkey. This was a play towards small businesses, and not an 'Inspect Element' hook.
Meanwhile, integrated devtools started with Chrome in 2008, two years after Firebug was released in 2006. My guess is Chrome wanted to provide a browser experience that was noticeably superior to a variety of demographics, and gain marketshare on merits. Meanwhile, IE began a huge effort to prove that they're not an old dinosaur of a browser holding the web back, but they didn't have easily-installable addons, so they built it in. These factors created pressure on Mozilla [1] to improve their devtools and consider shipping them with the browser.
[1] https://news.ycombinator.com/item?id=12042767#12044962
The Netscape had a distribution called Communicator that shipped the browser 'Navigator' alongside a mediocre but serviceable WYSIWYG editor 'Composer'. Other products were included too: an email client, and for a while, a Calendar; the codebase lives on as Mozilla Seamonkey. This was a play towards small businesses, and not an 'Inspect Element' hook.
Meanwhile, integrated devtools started with Chrome in 2008, two years after Firebug was released in 2006. My guess is Chrome wanted to provide a browser experience that was noticeably superior to a variety of demographics, and gain marketshare on merits. Meanwhile, IE began a huge effort to prove that they're not an old dinosaur of a browser holding the web back, but they didn't have easily-installable addons, so they built it in. These factors created pressure on Mozilla [1] to improve their devtools and consider shipping them with the browser.
[1] https://news.ycombinator.com/item?id=12042767#12044962
> Meanwhile, integrated devtools started with Chrome in 2008, two years after Firebug was released in 2006.
I'm very very sure integrated devtools could be traced back to WebKit Inspector Tool[1] in 2006 (with Drosera[2], the JavaScript inspector, being separate application). Then in 2007, the WebKit team rebuilt the Inspector Tool into Web Inspector[3] and merge Drosera into it. Chrome inherited the Web Inspector when it was released in 2008. I even remembered the first few versions of Chrome still has the Mac metal looks (even when running on Windows).
[1]: https://webkit.org/blog/41/introducing-the-web-inspector/
[2]: https://webkit.org/blog/61/introducing-drosera/
[3]: https://webkit.org/blog/108/yet-another-one-more-thing-a-new...
I'm very very sure integrated devtools could be traced back to WebKit Inspector Tool[1] in 2006 (with Drosera[2], the JavaScript inspector, being separate application). Then in 2007, the WebKit team rebuilt the Inspector Tool into Web Inspector[3] and merge Drosera into it. Chrome inherited the Web Inspector when it was released in 2008. I even remembered the first few versions of Chrome still has the Mac metal looks (even when running on Windows).
[1]: https://webkit.org/blog/41/introducing-the-web-inspector/
[2]: https://webkit.org/blog/61/introducing-drosera/
[3]: https://webkit.org/blog/108/yet-another-one-more-thing-a-new...
It's already been mentioned; the comment about integrated tools first showing up in Chrome was off.
But Safari wasn't the first either. WebKit Inspector was built under Dave Hyatt after being lured to Apple. It was meant to bring the tools available to Mozilla developers over to WebKit/Safari. Joe Hewitt's DOM Inspector was checked in to the Mozilla codebase in 2001, and Robert Ginda's Venkman JS debugger in 2003.
(After leaving Netscape, Hewitt took a second run at integrating both tools' featuresets, and that's where Firebug came from.)
But Safari wasn't the first either. WebKit Inspector was built under Dave Hyatt after being lured to Apple. It was meant to bring the tools available to Mozilla developers over to WebKit/Safari. Joe Hewitt's DOM Inspector was checked in to the Mozilla codebase in 2001, and Robert Ginda's Venkman JS debugger in 2003.
(After leaving Netscape, Hewitt took a second run at integrating both tools' featuresets, and that's where Firebug came from.)
There’s a gap in the middle of your timeline that was filled by DOMi and Venkman. I seem to recall those being built in at one point, although I might be wrong (I wasn’t doing professional front-end dev at that point).
Venkman was built into the Mozilla Suite [1], and it was also made into an addon for Firefox [2] when Firefox was released.
DOMi was built into Firefox since November 2003 if you used the Windows installer's 'Custom' installation and selected the checkbox for inclusion [3], then in Firefox 3 it was removed and made available as an extension [4]. It was also included in the 'Custom' installation of the 'Complete' Mozilla/Seamonkey Suite [3].
But Prototype.js came out in 2005, jQuery in 2006. Ajax the term was coined in 2005 [5][6][7]. We don't talk about the dark days before then.
[1] http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html [2] https://addons.mozilla.org/en-US/firefox/addon/javascript-de... [3] http://kb.mozillazine.org/DOM_Inspector [4] https://addons.mozilla.org/en-US/firefox/addon/dom-inspector... [5] http://www.quirksmode.org/blog/archives/2005/01/with_httpmap... [6] http://adaptivepath.org/ideas/ajax-new-approach-web-applicat... [7] http://www.quirksmode.org/blog/archives/2005/03/ajax_promise...
DOMi was built into Firefox since November 2003 if you used the Windows installer's 'Custom' installation and selected the checkbox for inclusion [3], then in Firefox 3 it was removed and made available as an extension [4]. It was also included in the 'Custom' installation of the 'Complete' Mozilla/Seamonkey Suite [3].
But Prototype.js came out in 2005, jQuery in 2006. Ajax the term was coined in 2005 [5][6][7]. We don't talk about the dark days before then.
[1] http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html [2] https://addons.mozilla.org/en-US/firefox/addon/javascript-de... [3] http://kb.mozillazine.org/DOM_Inspector [4] https://addons.mozilla.org/en-US/firefox/addon/dom-inspector... [5] http://www.quirksmode.org/blog/archives/2005/01/with_httpmap... [6] http://adaptivepath.org/ideas/ajax-new-approach-web-applicat... [7] http://www.quirksmode.org/blog/archives/2005/03/ajax_promise...
Oh yeah, the custom installation checkbox! Had forgotten about that, thanks for the memories.
Hrm... my apologizes, I stand corrected then. I started getting into web development after Netscape was, for all intents and purposes, dead and IE6 was king.
Well you're in luck, check out SeaMonkey composer today!
http://www.seamonkey-project.org/
http://www.seamonkey-project.org/
MS used to bundle a similar WYSIWYG editor with IE as well, Frontpage Express (a stripped-down version of the commercial MS Frontpage).
Well a WYSIWYG editor built in is not really comparable with the features of Firebug.
Sure, but Netscape Composer was a WYSIWYG editor as well, not a web page inspector/debugger like Firebug. Honestly, there was not much to inspect or debug in web pages at the time...
I don't know why but I like it this way - I at least have some assurance that what my dev tools show me is what the browser actually sees.
Best i can tell, at least Mozilla still adhere to the notion that the web empowered individuals by allowing anyone to publish something online.
Let me [not] cite Steve Ballmer...
Firebug has plug ins that I live by and aren't offered in the other browser tools. Firepath is one.
[deleted]
View Source has been around since the beginning, so it's not entirely new.
What's new seems to be all the work on making the dev tools comprehensive and "IDE-like", and I think that has as much to do with it is as useful to the companies building the browsers as the users of the browser. Such that Chrome probably added them in directly to save Google developer time and needing a separate IDE/toolkit/extension install, and the rest of the browsers followed.
It's interesting too in that Edge now uses the Dev Tools as a way to tier the user experience, such as the traditional View Source, out of the base experience. If you open the Dev Tools Edge asks if you are a developer and lights up a bunch of functionality that "ordinary" users don't need to see, like View Source.
What's new seems to be all the work on making the dev tools comprehensive and "IDE-like", and I think that has as much to do with it is as useful to the companies building the browsers as the users of the browser. Such that Chrome probably added them in directly to save Google developer time and needing a separate IDE/toolkit/extension install, and the rest of the browsers followed.
It's interesting too in that Edge now uses the Dev Tools as a way to tier the user experience, such as the traditional View Source, out of the base experience. If you open the Dev Tools Edge asks if you are a developer and lights up a bunch of functionality that "ordinary" users don't need to see, like View Source.
I believe WorldWideWeb.app didn't originally have View Source: it provided a WYSIWYG editor which was intended to be the main way to edit pages, AIUI.
I used to love dev work in FF. Anymore, it's always unstable and dev tools freeze a lot. I loaded up the latest dev edition a few days ago, a few minutes (and a bunch of beachball time) later, I was back in Chrome.
Fix your browser Moz -- I want to love FF again :(
Fix your browser Moz -- I want to love FF again :(
Not sure what's the issue for you; I've been using FF with its dev tools for years on Linux and Windows, and was always happy. Firebug had become way slower than the built-in dev tools, and Firefox is remarkably slower than Chrome, but not unstable at all (for me). And I like FF's dev tools better than Chrome's, except for performance investigation tools where Chrome is quite great.
hajile wrote: " I loaded up the latest dev edition a few days ago..."
I wonder if that meant the latest developer release, which would be expected to be unstable?
I wonder if that meant the latest developer release, which would be expected to be unstable?
He is likely referring to: https://www.mozilla.org/en-US/firefox/developer/?v=a
This is a developer focused edition of FF and shouldn't be unstable.
This is a developer focused edition of FF and shouldn't be unstable.
Dev edition is Aurora, which is basically alpha (more unstable than beta).
So you get new features more rapidly, and a lot of the feature flags are flipped on, without needing to use something as unstable as nightly.
So you get new features more rapidly, and a lot of the feature flags are flipped on, without needing to use something as unstable as nightly.
The lack of xpath support is an issue to me. Why doesn't FF have xpath support? Chrome and Firebug have/had this.
You mean this https://bugzilla.mozilla.org/show_bug.cgi?id=987877 ?
You might want to leave a comment on how/why (use case) you used it to help to priorize the bug.
There's a Firebug Gaps meta bug which depends on this: https://bugzilla.mozilla.org/show_bug.cgi?id=991806
You might want to leave a comment on how/why (use case) you used it to help to priorize the bug.
There's a Firebug Gaps meta bug which depends on this: https://bugzilla.mozilla.org/show_bug.cgi?id=991806
Same experience for me. I have FF installed on my laptop as a second/backup browser. I use it once every few days. First time after I installed it I have got a notification that it is launching slow and I should consider removing add-ons. This was the first time I ever launched it.
It constantly freezes and makes my laptop look like an oldie, even when it's not.
Chrome for me any day. I prefer to have ram clogged and no freezes.
Chrome for me any day. I prefer to have ram clogged and no freezes.
Is this a recent version of Firefox? Are you using the embedded dev tools, or are you trying to use Firebug?
Chances are your issue comes from a buggy plugin. I've filled my share of Firefox bug reports, but lately most problems I run into are due to buggy plugins.
Chances are your issue comes from a buggy plugin. I've filled my share of Firefox bug reports, but lately most problems I run into are due to buggy plugins.
I am very grateful for the firebug theme in dev tools. I find that UI much easier to use than Chrome or Firefox inbuilt dev tools.
The new dev tools are really sluggish compared to firebug. The new features are great, but hitting inspect element takes like 2 seconds now.
My experience is the opposite. Firebug was always full-featured, but it was an absolute sloth compared to the built-in FF and Chrome tools.
Maybe I'm doing something wrong. When I click inspect element, it first opens the dev tools and then inspects the body and after a moment of loading it hops to the correct element.
That moment of loading is what I expect from both FF's and Chrome's tools, neither is instant. But the last time that I used Firebug (which was almost two years ago, mind), opening Firebug would lock up the whole browser for several seconds, and then once it was open it would manage to slow down every other tab as well (which meant that I only kept it open while necessary, which meant that I'd have to endure the lock-up again the next time that I wanted to do anything).
I will say that having firebug open did cause major performance issues for regular browsing, but the performance of inspect element was quicker.
I am just happy they are really making an effort to improve the tools overall :)
I am just happy they are really making an effort to improve the tools overall :)
I loved firebug and was hesitant to switch to chrome, years ago, just to use the tool. To this day I prefer the UI over devtools. IMO, building that tool as an extension when it was built, is an empresive engineering feat. No doubt there was a lot of pain and learning!
Luckily, devtools in chrome has also come a long way and I'm sure it will keep getting better.
Luckily, devtools in chrome has also come a long way and I'm sure it will keep getting better.
I spent a good amount of time working on Firebug before the decision to rewrite it as DevTools was made. After that, it was hard to justify time on a EOL project and I had just started as employee 7 at Weebly.
But I loved working on it. The team was great, and special kudos to Honza for staying with it through all the years. We had so many ideas, to help in debugging and to help in learning. Many yet to come, I'm sure. So much left to be done in all the developer tools on all the platforms.
But I loved working on it. The team was great, and special kudos to Honza for staying with it through all the years. We had so many ideas, to help in debugging and to help in learning. Many yet to come, I'm sure. So much left to be done in all the developer tools on all the platforms.
Thanks for all your hard work! If you want to check out the new model of development take a look at the debugger, its the first in series of new panels coming to Firefox. https://github.com/devtools-html/debugger.html
Tabs and a history of the files you navigate to would be great to help debug firefox.
Thanks for working on such a great idea. I know that Firebug has saved me enormous amounts of time, and it was a big part of my tool chain for a long time.
I take it these are developed tools in Firefox. Does anyone use the developer edition? Is there any reason to?
There isn't a compelling reason imo, you get a dark console theme, slightly nicer / slimmer browser chrome, and a newer version of FF than the normal stable release, I'm not sure much else is different though.
More features, 2 releases (12 weeks) faster. If you can handle bugs from time to time (rarely), then it's all great (for me it is, writing this from the Dev Edition ;)
How can I revert it back? We had a major incident, I started Firefox to debug, of course it updated upon start, and replaced Firebug with this shit. Then Firefox crashed while I tried to click on the bubble which advertised to switch back. After the restart of Firefox there is no way to change back!? Stupid autoupdate crap, who in the right mind thought a feature incomplete tools is good to be forced upon users. Allow me to change back to Firebug, or Firefox is dead for me (until Servo replaces it).
The points are:
* Force it upon user
* Advertising "revert back", which restarts Firefox but Firefox crashes and after another restart forgets its settings - no one tested that option
* Firebug theme is just a theme, and several features and functionality found in default Firebug are still missing in their DevTools. The usability is different, especially in the AJAX/console tab. And where is a proper DOM tab?
* worst thing, it happened during a major incident, I login in remotely to my workstation just to find out my Tool changed under my feet completely, with all prior knowledge useless. I had to use Chrome DevTools which has more features, but even it lacks features as mentioned above - Firebug was the most matured Tool after all.
* Firefox still hasn't proper multi-process support, if you understand multi more than two processes. It's a far cry from what IE8+ and Chrome offer.
* Force it upon user
* Advertising "revert back", which restarts Firefox but Firefox crashes and after another restart forgets its settings - no one tested that option
* Firebug theme is just a theme, and several features and functionality found in default Firebug are still missing in their DevTools. The usability is different, especially in the AJAX/console tab. And where is a proper DOM tab?
* worst thing, it happened during a major incident, I login in remotely to my workstation just to find out my Tool changed under my feet completely, with all prior knowledge useless. I had to use Chrome DevTools which has more features, but even it lacks features as mentioned above - Firebug was the most matured Tool after all.
* Firefox still hasn't proper multi-process support, if you understand multi more than two processes. It's a far cry from what IE8+ and Chrome offer.
A good question. But I guess people downvote it since this is not the correct platform for this kind of question.
I ran into the same exact scenario. I tried to get moving with the devtools and while it looks similar and breakpoints seem to work better, getting acclimated was wasted time that I would rather have spent after the production issue was resolved.
That being said, I can't fault Mozilla for this. I've known for some time that Firebug was on it's way out.
That being said, I can't fault Mozilla for this. I've known for some time that Firebug was on it's way out.
My weekly experience with the Firefox Dev tools:
Get an exception in my concatenated is source.
See some unintelligible traceback with the mangled function names (despite the file having a source map)
Click on one of the stack links
See how Firefox tries to load my 10mb dev JS file in view-source:// and then crashes.
Repeat.
Get an exception in my concatenated is source.
See some unintelligible traceback with the mangled function names (despite the file having a source map)
Click on one of the stack links
See how Firefox tries to load my 10mb dev JS file in view-source:// and then crashes.
Repeat.
I switched to firefox dev tools a year ago (through the dev edition of firefox) and I absolutely love them, but the source map support has been really inconsistent. Sometimes it works, but almost always it doesn't :(
I haven't used Firefox/Firebug dev tools in ages. What advantages/disadvantages does Firefox/Firebug dev tools have over Chrome dev tools?
For instance, I like the inspector much better as it has vertical/horizontal lines which helps with alignment. Also I like the new (Firefox 52) "invisible" text nodes feature.
Overall, I like the (dark) theme UI/UX better, and also the DOM node hightlighting better.
The eyedropper and the full page screenshot tool are great too (do not know if Chrome also has it). And using all these tools from the devtools command line: https://developer.mozilla.org/en/docs/Tools/GCLI
There are drawbacks like the new debugger which is missing a lot common tiny usability features currently (making it hard to use) - and it's still buggy. But it's rewritten from scratch using modern technologies like react/webpack. So it's evolving fast.
Edit: Fixed typos.
Overall, I like the (dark) theme UI/UX better, and also the DOM node hightlighting better.
The eyedropper and the full page screenshot tool are great too (do not know if Chrome also has it). And using all these tools from the devtools command line: https://developer.mozilla.org/en/docs/Tools/GCLI
There are drawbacks like the new debugger which is missing a lot common tiny usability features currently (making it hard to use) - and it's still buggy. But it's rewritten from scratch using modern technologies like react/webpack. So it's evolving fast.
Edit: Fixed typos.
[deleted]
I can see the "built in Firebug" user interface building in front of my eyes. The top bar appears and a good 100-300 msec later the second bar with the tabs draw. Toggle F12 mutliple times, it's slow every time (you'd think it's not necessary to redraw everything and that this window could be cached somewhere?). I'm on 50.1.0 Windows 7 x64
With "Electrolysis" isn't that supposed to run even faster than the Firebug add on ?
With "Electrolysis" isn't that supposed to run even faster than the Firebug add on ?
He lives in you, he lives in me
He watches over everything we see
Into the waters, into the truth
In your reflection, he lives in you
With Firebug, the user could detach the Firebug window from the browser and position it separately on screen. Firebug could be enabled for any tab and the contents of the Firebug window would dynamically change to reflect the browser tab with focus. In DevTools (and also in Chrome), this mode is not an option. Instead, the user has two options, both of which are less desirable:
1. Open a separate DevTools window for each tab. This bloats the window stack in the same way browsers did generally before the advent of tabs, making it a poor option.
2. Leave the DevTools docked inside the browser window. This is poor because large screen real-estate cannot be properly utilized by positioning the DevTools separate from the browser window. Despite an abundance of screen real-estate, either a chunk of the browser frame needs to be consumed with the DevTools or the browser is made awkwardly wide/tall which adversely affects all tabs that do not have the DevTools open.
Because window management and usable screen real-estate is so critical to my productivity, this very specific behavior of Firebug is what I miss more than anything. The only Bugzilla bug I have seen about the matter [1] is fairly unpopular, however.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1219917