Thank you! The decision to integrate Firebug in the developer tools of Firefox will bring me back to this fantastic tool, that helped me a lot when I started coding for web :) - If you fix the dark theme Inspector view (Windows - haven't tested it on OSX jet, but I mention it would be the same), this would be perfect!
I get a message "Firebug could not be installed because it is not compatible with Firefox 33.1". Will FB 3.0 only work with the Developer Edition? It would help to call that out as the error, if that is indeed the case.
Il giorno lunedì 10 novembre 2014 15:31:18 UTC+1, Jan Honza Odvarko ha scritto:
Unfortunately it's still plagued by the issue 7515, it doesn't hit breakpoints in iframes if you reload just the iframe, as the built-in firefox's debugger since firefox 30.
Where is the edit button? I love the live edit feature of firebug and i dont see it on firebug 3.
Thank you but i dont mean this! On older firebug and on the upper left side of dom tree, there was an edit button wich let you live edit the document.
I am looking for native one
--
You received this message because you are subscribed to a topic in the Google Groups "Firebug" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebug/9nWmTvZv6lw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebug+u...@googlegroups.com.
To post to this group, send email to fir...@googlegroups.com.
Visit this group at http://groups.google.com/group/firebug.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebug/de333941-63e5-4ba8-af32-39ca39e26611%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Done creating a new bug report.
I have used the Firefox dev tools on a number of occasions, but I just find that they are missing little time-saving features and frequently don't work as expected.
Things like editing HTML/CSS and seeing the results immediately
trying to add a CSS rule (I have yet to find a way of doing this with the Firefox dev tools).
Or even when trying to debug JavaScript I often find that breakpoints don't even fire, even though they do in Firebug or Chrome dev tools.
I'm afraid it will copy not only the good parts but also the bad ones which made me switch to Firebug.
W dniu poniedziałek, 15 grudnia 2014 13:11:10 UTC+1 użytkownik Jan Honza Odvarko napisał:On Tuesday, December 9, 2014 9:51:55 PM UTC+1, Dominik Chrástecký wrote:Can you please provide a list of these "bad parts"?I'm afraid it will copy not only the good parts but also the bad ones which made me switch to Firebug.
(so we can avoid copying).
HonzaHi
I can give you three examples:
1. In classic Firebug, when you right somewhere inside Style column in HTML tab you can add css rule/inline style to the currently selected tag.
2. One window for each site when working with unpinned version (I think it's called something like that).
I really hate both Chrome and FF tools because of that. When I have few sites opened at the same time and I switch between them a lot I always loose track of which tool window is active on second LCD. Firebug doesn't have this problem because it just switch content within the same window.
3. All the features that are at right click menu - exact depends on context.
Those two are mine but I think there are much more those small things that makes classic Firebug better for its users. Many are even not noticeable...
On Monday, December 15, 2014 4:13:13 PM UTC+1, TheTester wrote:W dniu poniedziałek, 15 grudnia 2014 13:11:10 UTC+1 użytkownik Jan Honza Odvarko napisał:On Tuesday, December 9, 2014 9:51:55 PM UTC+1, Dominik Chrástecký wrote:Can you please provide a list of these "bad parts"?I'm afraid it will copy not only the good parts but also the bad ones which made me switch to Firebug.
(so we can avoid copying).
HonzaHi
I can give you three examples:
1. In classic Firebug, when you right somewhere inside Style column in HTML tab you can add css rule/inline style to the currently selected tag.Adding a new CSS rule works (almost) the same within the DevTools. See my comment above. Adding an inline style works by editing the Element rule.
As mentioned before, both teams try to close such usability gaps. Each missing feature should be requested in a separate issue, so they can be tracked individually.
Sebastian
I just upgraded my Firebug version to 3a6, on my Firefox Developer Edition 36.0a2, and there is a problem. The dark theme of this Firefox' version disappears ! Only the FF default theme is available. The only workaround I found i disabling Firebug.
I was using the 2.0.7 but the beta version of Firefox. When I updated to FireFox beta 36 Firebug stopped working.
Formerly from the console, the request would expand and show the headers, params and nicely parsed and formatted JSON when available. There are several problems that I see with the new interface.
- The viewing the request pops up in a window. The window goes to the top left monitor area, instead of staying where firebug is opened. Annoying.
- I turned on the response body, but it will not retrieve the whole thing, only a part until I click to retrieve the rest.
- Even after I retrieve it all, the JSON parsing window is gone, which means I have to copy it from the window into another editor and format there.
The response no longer is nicely formatted either. The response body is big long string of params. When you are running online application with anywhere from 3 to 50 posting params this again is a PITA to read.
I find it disappointing that a decision was made to "merge" the two tools in FireFox and apparently the builtin tools take precedence.
Firebug was far better almost across the board. Hears to hoping it can regain that former usefulness before version 3 is required by the general audience and not just those on beta tracks.
A) Wondering about the DOM panel in 3.
In 2 you could select from a list of iframes to viewr their DOM, I do not see that in 3. Is it there somewhere?
B) Vertical panels, is this to be available in 3?
There are real reasons we have avoided using the built-in FF tools and nearly all the tools in other browsers. Without going into unnecessary detail, suffice it say that the reasons are self-evident when viewed side by side.
So, it is with increasing alarm that we are monitoring the convergence of FF dev tools and Firebug. The reasons for unifying a best-of-class utility and perhaps the worst are not clear to us, but it seems inevitable.
With respect to the current post, we use firebug *exactly* this way (as do many folks) in an ajax based environment. We develop single page ajax web apps and the console-based ajax-http read-out is **critical** to us, not only for the headers (and other POST or GET parameters) but for the JSON returns as well.
Note that we also use kendo widgets (as well as others) that employ a Data Source object that permits ajax fetching of parameters through its transport property. These widgets range from charts to dropdown to grids. It is critical to our dev work that we be able to see this interaction in context.
Note finally that we also use many Deferred objects to sequence certain UI functions, especially page init functions. Many times a jQuery "parent” ajax call wraps these Deferreds which may embed a series of kendo-based ajax transport-based data fetches; the result is a series of server interactions that must be executed in sequence. All of this is required due to the anomalous nature of javascript threading. In debugging, we often drop console messages within these contexts to make sure the sequences execute correctly. The presence of the ajax-http console is indispensable here.
My team has disabled the FF auto-update on the dev profiles since we are worried that that we will lose the tools we need here.
Please do not compromise these and other features in the next version of this amazing tool. We have a theory that the folks at Google and Firefox (and Apple) who have developed the various browser-native tools are NOT web app developers and do not really understand the reasons that firebug is so effective - - and popular.
Firebug always had some nifty UI features other devtools don't have. Though note that the Firebug Working Group and the Firefox DevTools team work together to improve the UX of both tools.
Having all the above said, I'm not actively working for the FWG. I just wanted to provide some feedback on those questions as it seems nobody answered them so far.
Sebastian
As mentioned before both teams, the Firebug Working Group and the DevTools team are working together to close those usability gaps between the DevTools and Firebug. If you have more of those UX things that are missing, you should report them.
Hi,
Formerly from the console, the request would expand and show the headers, params and nicely parsed and formatted JSON when available. There are several problems that I see with the new interface.
- The viewing the request pops up in a window. The window goes to the top left monitor area, instead of staying where firebug is opened. Annoying.
- I turned on the response body, but it will not retrieve the whole thing, only a part until I click to retrieve the rest.
- Even after I retrieve it all, the JSON parsing window is gone, which means I have to copy it from the window into another editor and format there.The response no longer is nicely formatted either. The response body is big long string of params. When you are running online application with anywhere from 3 to 50 posting params this again is a PITA to read.
Did you try out the Network panel? It shows the data inline, displays the response body and POST parameters as expected and also parses JSON.
I just created bug 1125985 to link the console entries with the Network panel instead of opening the popup window.
I find it disappointing that a decision was made to "merge" the two tools in FireFox and apparently the builtin tools take precedence.
The introduction of e10s would have required to rework huge parts of Firebug's code, anyway. Because the Firebug team only consists of a handful of people, the decision was recreate Firebug based on the DevTools and use their infrastructure in order to let Firebug survive.
Firebug was far better almost across the board. Hears to hoping it can regain that former usefulness before version 3 is required by the general audience and not just those on beta tracks.
As mentioned before both teams, the Firebug Working Group and the DevTools team are working together to close those usability gaps between the DevTools and Firebug. If you have more of those UX things that are missing, you should report them.
I appreciate your response. I would like to note a few things to make sure they do not slip through the cracks.Someone at Mozilla is messing up your time table as the beta version of FireFox will not run FireBug 2.0.7. Or if it can, but a setting needs flipped, it would be appreciated if someone could point this out. (I got the latest beta release this morning, beta 4, to test.)
The Nifty and better thought out UX/UI/Tools of Firebug of lore is THE THING that set Firebug apart from all other developer tools.
...
it's sad to see 1/2 a decade+ of development go down the drain...
On Monday, January 26, 2015 at 11:03:42 PM UTC+1, Sebastian Zartner wrote:
The real problem is that this situation shouldn't have happenedAs mentioned before both teams, the Firebug Working Group and the DevTools team are working together to close those usability gaps between the DevTools and Firebug. If you have more of those UX things that are missing, you should report them.
Firefox had the best tool, and instead of working from the start with the Firebug team, they created a new team that obviously didn't use Firebug and instead they recreated from scratch everything, throwing away all the ideas, details, polishment that existed because they thought that they could do it better.
Web Developer and the new Firebug 3.0 UX/Capabilities are more or less on par with the Chrome/IE's developer tools which are very Inaccessible, limited and more or less a waste of time.
...in favor of such a dumbed down, poorly thought out, very inaccessible UX/Tool.
...but the blindness of the people heading Mozilla is astonishing.
The firefox tools really suck - they are clearly not created by web developers and are actually worse than the Chrome and IE and Safari tools.
Every single web developer who relies of FB (and I have never met a *single* serious developer that does not) will freak out if the new version of FB reflects the goofy ineptitude of the current FF dev tool.
Now we see "hey, if there's something missing go here and file a bug", not only from you, other people say the same, but why should we waste our time filing bugs to make the Firefox dev tools work like it should when there are already tons of such requests already filed
and in the release notes of Firefox we see that the work is focused on things like web audio, virtual reality, and the like instead of working on the basics used by 90% of the people 90% of their time?
File a bug report or feature request? This is silly - do they actually not know that every developer uses firebug? Read a book sometime or do a tutorial - they always reference firebug.
OK - here's a feature request:1) please make your tools do **exactly** what firebug does.2) make it look the same, tooThat's simple, right?
The new "Firebug 3.0" is NOT Firebug. ... Firebug 2.0.7 is the Last version of "Firebug"
On Monday, January 26, 2015 at 5:03:42 PM UTC-5, Sebastian Zartner wrote:
Hi,
Note that for Firebug 2.0.7 you need to have e10s disabled.
Nice to say, but there is no option I see to disable it in the general configuration screen your link points to. (I had checked this before.) When I do a abount:config there is an option for print.enable_e10s_testing which is defaulted to true. Is that what you may be referring to?
Did you try out the Network panel? It shows the data inline, displays the response body and POST parameters as expected and also parses JSON.
I just created bug 1125985 to link the console entries with the Network panel instead of opening the popup window.
Yes, I checked the network panel. While it is easier to see the information on the right side panel, it is a HUGE amount of spam where it used to just show my request in the console
not only that, but the JSON panel does NOT parse out the nice pretty json such as the earlier firebug did. It is just a long string.
That is fine, but looks like someone's timing is really off since I HAVE to use FireBug 3 to have anything work with FireFox 36.0.
The statement in teh linked page for e10S is, "The e10s team estimates e10s with a single content process will be enabled in Firefox Release by the end of 2015" Well we are in January. I cannot find anywhere that states, "version x of firefox will have the e10s enabled". The one site I did find mentions the tag "browser.tabs.remote.autostart" which is set to false, yet the 2.0.7 will not work.
You don't. Firebug 2.0.7 is even working in Firefox 38.0 in case e10s is disabled.The statement in teh linked page for e10S is, "The e10s team estimates e10s with a single content process will be enabled in Firefox Release by the end of 2015" Well we are in January. I cannot find anywhere that states, "version x of firefox will have the e10s enabled". The one site I did find mentions the tag "browser.tabs.remote.autostart" which is set to false, yet the 2.0.7 will not work.
Please start another thread as this one gets quite lengthy and it's hard to track such issues individually.
Sebastian
I'm generally not fond being peed upon and calling it a warm spring rain. Call a spade a spaid. The Web Developer tools in Firefox have been ARound for a good while. God knows I said "yes" to their installation of them about 5(?) years ago. And they are exactly as utterly useless today as they were 5 years ago. Not in the same state as they were but still it's like driving a car that has 4 wheels but is missing one of the wheels, the steering wheel, the driver seat, the lever to the pedal and the windshield.
The ex-Firebug team did an awesome job. They went to the Olympics, They took first place and took home gold.
The new FWG team knows more about closing tickets with canned responses such as (Submit a ticket) and have somebody else close the ticket with a canned response (this would be duplicating features) when it in fact is not.
They more or less carry very similar stances and arguments as the team...
On Tuesday, January 27, 2015 at 5:23:58 PM UTC+1, Richard Muse wrote:On Monday, January 26, 2015 at 5:03:42 PM UTC-5, Sebastian Zartner wrote:Hi,Nice to say, but there is no option I see to disable it in the general configuration screen your link points to. (I had checked this before.) When I do a abount:config there is an option for print.enable_e10s_testing which is defaulted to true. Is that what you may be referring to?
My fault. Firefox 36 doesn't have e10s enabled by default. You can easily see whether e10s is enabled. When the browser tab texts are underlined, it is enabled. In Nightly (38) Enable E10S (multi-process) is the first option you see when you open the browser options.
Did you try out the Network panel? It shows the data inline, displays the response body and POST parameters as expected and also parses JSON.
I just created bug 1125985 to link the console entries with the Network panel instead of opening the popup window.Yes, I checked the network panel. While it is easier to see the information on the right side panel, it is a HUGE amount of spam where it used to just show my request in the console
Which 'spam' is that?
not only that, but the JSON panel does NOT parse out the nice pretty json such as the earlier firebug did. It is just a long string.
It works fine for me on this test case:
http://www.softwareishard.com/firebug/tests/1275/Issue1275.htm
That is fine, but looks like someone's timing is really off since I HAVE to use FireBug 3 to have anything work with FireFox 36.0.
You don't. Firebug 2.0.7 is even working in Firefox 38.0 in case e10s is disabled.
Sebastian
As I just figured out, I can filter to XHR to get just the requests, so that helps as well.
On Thursday, January 29, 2015 at 9:08:48 PM UTC+1, Richard Muse wrote:On Tuesday, January 27, 2015 at 5:23:58 PM UTC+1, Richard Muse wrote:On Monday, January 26, 2015 at 5:03:42 PM UTC-5, Sebastian Zartner wrote:Hi,Nice to say, but there is no option I see to disable it in the general configuration screen your link points to. (I had checked this before.) When I do a abount:config there is an option for print.enable_e10s_testing which is defaulted to true. Is that what you may be referring to?
My fault. Firefox 36 doesn't have e10s enabled by default. You can easily see whether e10s is enabled. When the browser tab texts are underlined, it is enabled. In Nightly (38) Enable E10S (multi-process) is the first option you see when you open the browser options.I have Beta 36. As mentioned by Constrained Serenity, we see a complete FireFox lock up when 2.0.7 is installed. The other people in the office that were beta tracking went back to 35 in order to keep using FireBug. The tabs are not underlined and I see no where to turn e10s off, so I am still stuck there. I have attached the option screen shot (trimmed down) where you can see e10s is not an option.
On Thu, Jan 29, 2015 at 3:08 PM, Richard Muse <frm...@gmail.com> wrote:As I just figured out, I can filter to XHR to get just the requests, so that helps as well.Do you literally mean "filter" -- that is, you only see the Net panel items you're interested in? Can you please explain how you do that?
This is also described in the wiki: https://getfirebug.com/wiki/index.php/Net_Panel#Filters
The Console panel also has pre-filtering options (also described in the wiki), which allow you to just log XHR requests if you wish so:
One of the most commented missing features in Firebug 3 has been XHR debugging/logging.
And yes again, we are listening, it's now in Firebug 3
(check out alpha 8)
https://github.com/firebug/firebug.next/releases/tag/firebug-3.0.0-alpha.8
(if sucessfull, it can become native feature)
Thanks for the information. I have the Alpha 8 now and that is certainly, to my perspective, a noticable step. There is a small part missing from it though. The Params I would still have to go to the network tab. Also the View Source does not appear to do anything.
What next? I have two suggestions:1.Have a "Write my code" button that produces better javascript code for my project than I do. (See, I set the bar low!)
2A. Work on the debugger which can slow to a complete crawl on large files.
2B. The former firebug debug search would look through all the loaded files to find the searched text. Now it only appears to search the files, or if you put a # in the front, search in the currently opened file.
Another small note. I notice the network tab for the selected line now is white text on light grey background. Almost looks like it was blanked out.
On Tuesday, January 20, 2015 at 10:46:51 AM UTC+1, Mahks wrote:A) Wondering about the DOM panel in 3.
In 2 you could select from a list of iframes to viewr their DOM, I do not see that in 3. Is it there somewhere?
I assume you mean the property path, the breadcrumb path within the panel toolbar. Note that this was not a list of iframes. Allowing to switch between iframes was requested in issue 4173, though. You may want to create an issue for re-adding the property path.
Hi there, previously in Firebug 2 all AJAX requests and JS errors would be logged in the Console tab. This was nice and worked very well, but now AJAX requests are being logged in the Network tab, along with all other network requests, such as images, CSS files, etc. I know there are filters to filter out the stuff I don't want to see, but I much rather preferred AJAX requests being in the Console tab.Furthermore it was possible to "expand" a console entry and all the parameters were shown in a nice format. Now everything appears in the smaller sidebar and looks very cluttered. Please can this behaviour be reverted back to how it was in Firebug 2? Thanks.
Should we post bugs in this group or on Github?