Firebug 3 - next generation of Firebug

[Jan Honza Odvarko]

http://bit.ly/1wKR16L

Honza

[Noit Saab]

This is awesome news. I loved Firebug and when browsers started doing their built in firebug it was sad as I had no more need for Firebug. So it's real great to see it coming back with this new direction. Rather than compete it will join with Firefox tools! Super cool!

On Monday, November 10, 2014 6:31:18 AM UTC-8, Jan Honza Odvarko wrote:

http://bit.ly/1wKR16L

Honza

[Toby B.]

Excellent! I am noticing that if I enable Firebug in my shiny new copy of DeveloperEdition (35.0a2) on OSX, it forces the browser's theme to Firebug, which makes it very hard to some common tasks (for example, the location bar field's borders disappear and its text no longer highlights). Can Firebug coexist somehow with the default Dark and Light themes?

[Sebastian Zartner]

This is handled in issue #177.

Sebastian

[Daniel Almeida Gonçalves]

Just want to say thank you to all contributors of Firebug, you have helped me in a way I think I would not have the knowledge I have right now without your efforts. Beside that you have inspired so many people and products. Keep up the amazing work and can't wait for the alignment you proposed.

[Florian Steller]

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!

[Jan Honza Odvarko]

Thanks to all for the support!

On Tuesday, November 11, 2014 9:34:14 AM UTC+1, Florian Steller wrote:

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!

We are just working on a patch...

Honza

[les.m...@eperformancegroup.com]

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.

[Jan Honza Odvarko]

On Tuesday, November 11, 2014 1:46:06 PM UTC+1, les.m...@eperformancegroup.com wrote:

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.

Firebug 3 needs at least Firefox 35.0a2 (the current Aurora/Developer Edition channel), so currently it also works with the Nightly build (36).
https://nightly.mozilla.org/

Honza

[benjasHu]

Hi! 

I've just installed new Firefox Developer and Firebug 3 and it seems that DOM tab does not work (almost on my Windows 7).

Just refresh button appears in DOM tab. I click in the button and nothing happens...

Is this a bug or I am doing something wrong?

Thanks and congrats for update!

El lunes, 10 de noviembre de 2014 15:31:18 UTC+1, Jan Honza Odvarko escribió:

http://bit.ly/1wKR16L

Honza

[Emmanouil Pourikas]

Where is the edit button? I love the live edit feature of firebug and i dont see it on firebug 3.

[Stefano Manfrini]

Il giorno lunedì 10 novembre 2014 15:31:18 UTC+1, Jan Honza Odvarko ha scritto:

http://bit.ly/1wKR16L

Honza

 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.

Just for curiosity, is this a major issue only for me? (for the records i still have to work with firebug 1.12.8 and firefox 32.02.3, since firefox 33 removed support for the old debugging engine)

[Jan Honza Odvarko]

On Wednesday, November 12, 2014 11:31:12 AM UTC+1, Stefano Manfrini wrote:

Il giorno lunedì 10 novembre 2014 15:31:18 UTC+1, Jan Honza Odvarko ha scritto:

http://bit.ly/1wKR16L

Honza

 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.

Yes, this needs platform support (as I mentioned in this comment).
 
Honza

[Jan Honza Odvarko]

On Wednesday, November 12, 2014 12:04:37 AM UTC+1, Emmanouil Pourikas wrote:

Where is the edit button? I love the live edit feature of firebug and i dont see it on firebug 3.

1. Select the Inspector Panel.
2. Right click on an element
3. Pick "Edit As HTML"

Honza

[Emmanouil Pourikas]

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.

[Jan Honza Odvarko]

On Wednesday, November 12, 2014 12:38:28 PM UTC+1, Emmanouil Pourikas wrote:

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.

Ah, true, the feature I mentioned is not changing the page live.
Please create a new report here:
https://github.com/firebug/firebug.next/issues

Honza

[marcelo alfaro]

The search in Net disappeared (a must), I also liked the way the detail of the requests are shown in 2.06 also...
don't liked 3 much, I go for the 2.06 again...

cheers
marcelo

[NoiDue]

I am worried that it will no longer work with SeaMonkey :(

[Yonggang Luo]

Does firebug.next support for thunderbird 3?

在 2014年11月10日星期一UTC+8下午10时31分18秒，Jan Honza Odvarko写道：

http://bit.ly/1wKR16L

Honza

[Yonggang Luo]

Hope firebug.next can be running as a standalone XUL application,

that's should be fantastic, and debugging XUL application 

[Sebastian Zartner]

As the blog post indicates Firebug 3 is tightly integrated into the built-in DevTools. So it can only run where the DevTools are available, which is currently just Firefox.

Sebastian

[Yonggang Luo]

Thanks a lot, this answer makes a lot sense.

在 2014年11月25日星期二UTC+8上午6时31分25秒，Sebastian Zartner写道：

[Jan Honza Odvarko]

Here is a list of runtimes that are supported through remote debugging:
https://developer.mozilla.org/en-US/docs/Tools/Remote_Debugging

See this part explaining how to use browser debugger with XUL Runner 24+
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XULRunner/Debugging_XULRunner_applications#Browser_Debugger

HTH

Honza

[罗勇刚(Yonggang Luo)]

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.

[ericN]

Can you bring back the event tab in the inspector just like the v2+ has. It is very useful and you removed it.

[Jan Honza Odvarko]

On Tuesday, November 25, 2014 12:30:25 PM UTC+1, ericN wrote:

Can you bring back the event tab in the inspector just like the v2+ has. It is very useful and you removed it.

Can you please create a new bug report?
https://github.com/firebug/firebug.next/issues

Honza

[ericN]

Done creating a new bug report.

[Jan Honza Odvarko]

On Wednesday, November 26, 2014 12:29:11 PM UTC+1, ericN wrote:

Done creating a new bug report.

Thanks!

Just for the record:
https://github.com/firebug/firebug.next/issues/216

Honza

[Carth]

I was sorry to hear this news because I much prefer Firebug and its interface to the built-in Firefox dev tools. 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, or 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 have to switch to a computer that has my copy of Firefox with Firebug to actually get anything done.

I agree that it doesn't make sense to duplicate functionality that already exists, so I don't know what to say. I just think Firebug does most things significantly better and I haven't found the Firefox dev tools to be very usable.

[Dominik Chrástecký]

Not really happy about it, I always loved Firebug, because it's better than the built-in console. I'm afraid it will copy not only the good parts but also the bad ones which made me switch to Firebug.

Dne pondělí, 10. listopadu 2014 15:31:18 UTC+1 Jan Honza Odvarko napsal(a):

http://bit.ly/1wKR16L

Honza

[will]

Just wanted to chime in to say congratulations on the 3.0 alpha.

Thank you all for all of your work on Firebug.

Will

[Jan Honza Odvarko]

> I just think Firebug does most things significantly
> better and I haven't found the Firefox dev tools to be very usable.

Yes, we know that and we want to change that.
We also want to make sure that devtools are extensible
and existing Firebug extensions can be ported.

Honza

[Sebastian Zartner]

On Tuesday, December 9, 2014 4:58:35 PM UTC+1, Carth wrote:

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.

The team behind the DevTools know about that and have a bug for closing these gaps to Firebug. See bug 991806. Furthermore, as Honza already mentioned, the Firebug Working Group is also working on fixing gaps between both versions. So feel free to create bug reports for UI regressions, in case they are not already filed.

Things like editing HTML/CSS and seeing the results immediately

This is filed as bug 1067318 for HTML. CSS is already updated instantly while editing.

trying to add a CSS rule (I have yet to find a way of doing this with the Firefox dev tools).

It's working similar to Firebug since Firefox 33. I.e. right-click into the Rules panel and choose Add rule from the context menu. For more info see bug 966895.
 

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.

If you can break this problem down to a simple test case, please file it against the DevTools. Though before you do that you should try to reproduce your problem on Firefox Nightly as it might already be fixed there.

Sebastian

[Jan Honza Odvarko]

On Tuesday, December 9, 2014 9:51:55 PM UTC+1, Dominik Chrástecký wrote:

I'm afraid it will copy not only the good parts but also the bad ones which made me switch to Firebug.

Can you please provide a list of these "bad parts"?
(so we can avoid copying).

Honza

[TheTester]

Hi
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...That's why I tried to use new Firebug for some time but I had to get back to previous version.

[Sebastian Zartner]

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:

I'm afraid it will copy not only the good parts but also the bad ones which made me switch to Firebug.

Can you please provide a list of these "bad parts"?
(so we can avoid copying).

Honza

Hi
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.
 

2. One window for each site when working with unpinned version (I think it's called something like that).

In Firebug terminology this is called 'detached'.

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.

Good point. You may request this for Firebug 3.
 

3. All the features that are at right click menu - exact depends on context.

Yes, there are a lot of features missing from the context menu, especially within the Rules side panel.

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...

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

[TheTester]

W dniu poniedziałek, 15 grudnia 2014 18:20:16 UTC+1 użytkownik Sebastian Zartner napisał:

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:

I'm afraid it will copy not only the good parts but also the bad ones which made me switch to Firebug.

Can you please provide a list of these "bad parts"?
(so we can avoid copying).

Honza

Hi
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.
 

Yes...almost. There are things that are missing like right click on empty space in Rules.

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

It's great to here that you're trying your best. I really like for you to bring Firebug experience to the new level. I made my points only to give you some idea for differences. I wasn't do this to bash you or something ;)

[jez9999]

I've got a bad feeling about Firebug 3.  "tight integration with the existing Firefox platform" - what will that mean for SeaMonkey users running Firebug?  It doesn't have Firefox's devtools, and Firebug made a nice alternative.  Are you basically throwing SM support out the window?

Best regards,
Jeremy Morton (Jez)

[Sebastian Zartner]

Firebug was never officially supported SeaMonkey.

Though SeaMonkey allows remote debugging, so you should be able to get it to work similar like for Thunderbird.
You may also request to implement the DevTools directly within SeaMonkey.

Sebastian

[Sebastian Zartner]

I just realized that there is already a request for integrating the DevTools into SeaMonkey in bug 842942.

Sebastian

[saad.s...@gmail.com]

Hi,
why Firebug 3 has retrogressive?! in Firebug 2 we can take mouse over an element and press 'Delete' key to remove element, and then saving page. but in Firebug 3 is like Firefox default code editor(Inspect Element) , that we must move mouse over it, then click on element, then click on codes panel, and then press 'Del' to remove unwanted element.

[saad.s...@gmail.com]

Hi,
in Firebug 2 we can take mouse over an element and press 'Delete' key to remove element, and then saving page. but in Firebug 3 is like Firefox default code editor(Inspect Element) , that we must move mouse over it, then click on element, then click on codes panel, and then press 'Del' to remove unwanted element. please make like ver2. Thanks

[Thunderseb]

Hey there,


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.

Anyway, keep up the good work !


Le lundi 10 novembre 2014 15:31:18 UTC+1, Jan Honza Odvarko a écrit :

http://bit.ly/1wKR16L

Honza

[Jan Honza Odvarko]

On Tuesday, December 30, 2014 5:09:56 PM UTC+1, Thunderseb wrote:

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.

We had similar problem in the past, but it should be fixed in 3a6

Can you please report a new bug here:
https://github.com/firebug/firebug.next/issues

... and provide detailed instructions how to reproduce the problem.

Thanks!

Honza

[Sebastian Zartner]

The point is that Firebug switches the browser theme back to Australis.

Sebastian

[Richard Muse]

I was using the 2.0.7 but the beta version of Firefox. When I updated to FireFox beta 36 Firebug stopped working. I saw this was a chance to get it working and ensure that I tested the latest stuff before the other developers in the office got bitten by any issues.

Two quick things I see as massive steps back from our points of view. We are a heavily AJAX shop, so I am coming in from that perspective. This behavior may mimic the built in FirFox dev tools, but we did not use them for good reason.

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.

Just those two general items made FireBug a MUST for our development shop. The Alpha for 3 is so far harder to use (in our case) than Chrome's dev tools. At least I do not have to request the rest of my data manually every time I make a query, after moving the pop up window back over to the proper monitor and sizing it so I can see more than a few lines.

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.

I understand I am on beta and alpha tracks. I am not screaming, yet. A few months of not having a "useful" firebug might do it to me though. ;)

But for now, mostly Chrome it is.

[Mahks]

A) Wondering about the DOM panel in 3.

In 2 you could select from a list of iframes to view their DOM, I do not see that in 3. Is it there somewhere?
Also in 2 there was a "Window" link that would display the main page DOM, also not found.
I'm looking for the user defined properties these would show.

B) Vertical panels, is this to be available in 3?

The DOM view for the inspector is scrunched down to a quarter screen and I find I must continually adjust panel sizes to view it.

I too am a great fan of Firebug and found the FF native tools clumbersome, except for that nifty new performance tool...
My only complaint was the poor support for iframes after the JS2D implementation, aslo mentioned by Stefano Manfrini

[stephen taylor]

Hi

The work that the firebug group does in creating — by far — the best debug tool for web development is exemplary and we all appreciate it.

But I could have written this post myself on behalf on my dev group and, I suspect, so could many developers.

We use Firebug 2.07.

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.

Thanks

S

> --
> You received this message because you are subscribed to the Google Groups "Firebug" group.
> To unsubscribe from this group and stop receiving emails from it, 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/6ae16e75-4b05-4f7a-8a90-181428beed5d%40googlegroups.com.

[Sebastian Zartner]

Hi,

On Saturday, January 17, 2015 at 10:47:53 PM UTC+1, Richard Muse wrote:

I was using the 2.0.7 but the beta version of Firefox. When I updated to FireFox beta 36 Firebug stopped working.

Note that for Firebug 2.0.7 you need to have e10s disabled.

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.

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.
 

B) Vertical panels, is this to be available in 3?

As far as I can see not yet. Worth a new report.

On Tuesday, January 20, 2015 at 1:02:00 PM UTC+1, stephen taylor wrote:

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.

Please report those 'self-evident reasons' individually, so they can be fixed in Firebug 3.

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.

Reasons for the merging of both tools were mentioned above and in the first blog post to Firebug 3.

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.

Same question as above for Richard: Did you try out the Network panel?
 

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.

Note also bug 972655.

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

[Constrained Serenity]

The new Firebug 3 is very clumsy and is missing pretty much all of the features that have made Firebug an invaluable web development tool.

It's like Mozilla completely took over Firebug, fired everybody and replaced Firebug with the Kludgy tool they have been trying to pass off as a Web Developer tool.

Web Developer Tool has always been a gimped tool that has a very poorly thought out UX that is difficult to navigate, be it with the mouse, the keyboard or even your eyes as you try to ascertain what information is important and what is not. 
Accessibility? Almost Nothing can be selected, copy or pasted! How do you create a tool/UX that is designed purely for developers where you can't select anything?

And what happened to the Network Tab? It seems to have been so badly nerfed that it's almost like it might as well not be there? I couldn't do a single thing OOB in the Network tab that I used to do previously.

[Constrained Serenity]

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

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.
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.

it's sad to see 1/2 a decade+ of development go down the drain in favor of such a dumbed down, poorly thought out, very inaccessible UX/Tool.

[alfonsoml]

On Monday, January 26, 2015 at 11:03:42 PM UTC+1, Sebastian Zartner wrote:

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.

The real problem is that this situation shouldn't have happened, but the blindness of the people heading Mozilla is astonishing.
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.
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?

I don't care about that, I just want to be able the see the DOM, edit the HTML, adjust CSS, find out why something doesn't work, copy those changes, debug javascript, have breakpoints that work, see the network requests, with a friendly UI that doesn't makes me wonder in which strange world those developers live that they think that they can change the whole browser UI instead of having the browser adapt to my OS.

If anyone wants to get ideas about how to improve the Firefox dev tools, they just have to open Firebug, look at each tab, check the options, look at the context menu, etc... and put all of them back into those "dev tools". Then look at the work done in Chrome with regards to Mobile emulation, not just plain window resizing like Firefox, really powerful emulation and again put all those features there, and the CSS changes pane in IE, holy cow man, that's better than slided bread.

Meanwhile they can suggest us to debug other browsers with their tools, but why should I use a plastic car connected with a wire to a real car to learn to drive when I can just jump into the real car that has many more features ?

[Richard Muse]

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?

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.

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. Again I have to copy out to format properly for reading by human eyes.

 

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.

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.

 

 

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.

As was mentioned in other posts after this one, the easiest way to figure out what is missing is open the FireBug 2.0.7 and the Firebug 3.0 tabs side by side. If it is in 2.0.7 and not in 3.0 then it is 90% chance it should be in the 3.0.

[stephen taylor]

Once again I completely agree with @ alfonsoml. I mean, what could these people actually be thinking? Firebug is by far the most popular and widely used web development/debug tool. I still do not understand what is happening here, much less why.

Is firebug actually going way? Why? 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.

Does these folks at Moxilla know they will be alienating their strongest constituency - developers? 

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, too 

That's simple, right?

[Constrained Serenity]

Stephen please describe the usage scenario for your recently submitted bug "

1) please make your tools do **exactly** what firebug does. 

2) make it look the same, too "

Please note all of these features are already implemented in Firebug 3.0 and your request would be duplicating features. I am closing this bug. Thanks and have a great day..

And yes, I am trolling after reading several tickets on Github posted by Firebug 3.0 developers responding to people tickets/suggestions (some of which are in this thread)

Did they offshore Firebug 3.0 development to some Indian company?

[Jan Honza Odvarko]

A few notes from this thread to mention:

> I much prefer Firebug and its interface to the built-in Firefox dev tools.

> The new Firebug 3 is very clumsy and is missing pretty much all of the features that have made
> Firebug an invaluable web development tool.

> 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.

> If anyone wants to get ideas about how to improve the Firefox dev tools, they just have to open
> Firebug, look at each tab, check the options, look at the context menu, etc...

etc.

Here is my response:

1. I understand all the complaints in this thread and our project goals are set precisely to answer them.
2. Yes, Firebug 3 is not ready yet (it's in alpha phase) and we (FWG) are working hard to move closer to what Firebug 2 is. And yes we need more time.
3. We all (FWG + Mozilla) know about Firebug 2 UI/UX advantages and the goal is to integrate them either directly to devtools or to Firebug 3.
4. To be fair, native devtools have also some advantages (e.g. stability, small memory footprint, security, e10s support, remotability, etc.), so taking the best from both tools and build one that is the best is the right goal.
5. It's important to understand that FWG is pretty small, 1 full time dev (me, the team leader) and a few contributors, so work is not going forward as fast as you would perhaps expect.
6. I have to mention that Firebug is an open source and even if I understand that everyone in this thread is probably already overloaded by work, we appreciate contributions.
7. It isn't feasible to continue with Firebug as separate full feature in-browser development tool. An effective strategy is cooperation with the devtools team and bring back Firebug 2 UI/UX.
8. No Firebug 3 isn't offshored to an Indian company (please be friendly, this kind of comments could be offending).

Honza

[Erik Krause]

Am 28.01.2015 um 08:13 schrieb Jan Honza Odvarko:
> 5. It's important to understand that FWG is pretty small, 1 full time
> dev (me, the team leader) and a few contributors, so work is not going
> forward as fast as you would perhaps expect.

[...]

> 7. It isn't feasible to continue with Firebug as separate full feature
> in-browser development tool. An effective strategy is cooperation with
> the devtools team and bring back Firebug 2 UI/UX.

All that sounds as if it would be better to convince the devtools team
to integrate firebug features and UI into devtools and use the manpower
of fb team for consultancy only. To build fb3 on top of devtools and do
all the coding work yourself seems like a waste of qualification and
knowledge.

Firebug team pioneered developer tools. They deserve more than only
correcting and working around the incompetence of Mozilla developers.

best regards
Erik Krause

[Richard Muse]

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.)

Since the timetable is pushed up, that is part of the reason for the aggravation. Most, if not all of us understand the Alpha version, but it looks like FireFox will be in release before you get out of Alpha. This means that FireBug, our beloved tool, will not be available for testing against the latest release. This is more of a PR problem, since we can just keep the last release of FireFox, but a problem it still is, until customer ONLY have problems in the latest version then... Perception can become reality.

I appreciate the small team, I do not have any answers to help you with that one. As another posted noted, maybe try and poke the Mozilla dev teams to stop adding features that will either be very limited use or not at all, and concentrate on helping the developers, who push their software, into working with you.

As before, holding optimism that all will work out, but the time tables are dimming that hope.

[stephen taylor]

@Honza

Your responses are (as usual) great and make a lot of sense - at least mostly.  The one thing I expect you are hearing (as many of us are) is the anxiety reflected in this thread. 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. And I really do mean that as harshly as it sounds. Many of us spend our professional lives creating products with great UI and functionality required by users. The FF dev group that has developed their native tools seem oblivious to how web-based apps are developed. They seem tone deaf and do not seem to understand how important FB is in driving users to the product. 

We appreciate all your work.

[Constrained Serenity]

Honestly given the direction and choices that Mozilla's team has been making in the past that very well could more intentional than it is accidental


The new "Firebug 3.0" is NOT Firebug. It is The failed web tools that Mozilla has been working on for 2-4 years that still are failing being given Firebug's name.

Firebug 2.0.7 is the Last version of "Firebug"

I see it sort of as Windows XP/7 versus Windows 8/9 or Office 2010 versus 2013. Every interface dumbed down. All important/power user features removed or requires a ton of clicks (and then eventually removed because metrics says nobody was using that feature). Every interface made as inaccessible as possible (copy paste must go in all these UX). Interface and icons have as much colors/definition removed as possible. In the case of Firebug 3.0 I thought the Dark Grey Text against Black background was rather amusing (and unusable).

On Wednesday, January 28, 2015 at 8:22:46 AM UTC-6, Richard Muse wrote:

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.)

[Sebastian Zartner]

On Tuesday, January 27, 2015 at 3:45:10 AM UTC+1, Constrained Serenity wrote:

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 Tuesday, January 27, 2015 at 4:59:52 PM UTC+1, alfonsoml wrote:

On Monday, January 26, 2015 at 11:03:42 PM UTC+1, Sebastian Zartner wrote:

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.

The real problem is that this situation shouldn't have happened

I totally agree with that.

On Tuesday, January 27, 2015 at 4:59:52 PM UTC+1, alfonsoml wrote:

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.

The team behind the Firefox DevTools and the Firebug Working Group should definitely have worked more closely together in the past. The past can't be undone, but at least the teams work together now.

On Tuesday, January 27, 2015 at 3:45:10 AM UTC+1, Constrained Serenity wrote:

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.

On Tuesday, January 27, 2015 at 4:59:52 PM UTC+1, alfonsoml wrote:

...but the blindness of the people heading Mozilla is astonishing.

On Tuesday, January 27, 2015 at 5:24:50 PM UTC+1, stephen taylor wrote:

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.

On Wednesday, January 28, 2015 at 3:58:43 PM UTC+1, stephen taylor wrote:

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.

While the UI of the Firefox DevTools still has a lot of potential to be improved and definitely lacks some basic features, they are not as bad as you illustrate them. Actually they got quite powerful in the relatively short time they exist.

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

Because the team might miss to (re-)implement certain features some people are missing.

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?

You should ask that to the Firefox DevTools team. Note that they use UserVoice as a system to get user input and prioritize their work.

On Tuesday, January 27, 2015 at 5:24:50 PM UTC+1, stephen taylor wrote:

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. 

I wished every developer used Firebug, though that's definitely not the case. From my experience most people nowadays use the Chrome DevTools.

OK - here's a feature request: 

1) please make your tools do **exactly** what firebug does. 

2) make it look the same, too 

That's simple, right?

That's the goal, though technically that is extremely difficult to do.

On Wednesday, January 28, 2015 at 11:10:31 PM UTC+1, Constrained Serenity wrote:

The new "Firebug 3.0" is NOT Firebug. ... Firebug 2.0.7 is the Last version of "Firebug"

This is also my thinking as Firebug 3.0 tries to be something else. Though not because it's currently still lacking many different parts of functionality Firebug 2.0 had (note that it's still in alpha phase) but more because it's now an extension to the DevTools instead of an independent tool.
I would have preferred if Firebug had stayed an individual tool.

I want to emphasize again that the above reflects my personal opinion. I am not working for the FWG anymore since December last year.

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,

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?

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.

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

[Constrained Serenity]

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

Firebug 2.0.7 is very buggy in 37 and up. Almost every single time Script or Network console was open  and a JSON post was done and data was retrieved and the UX was inserted the whole TAB would freeze. Nothing in the tab would work. No HTML could be interacted with (though it did get updated). Even the Browser's UX was unresponsive in that you could click in UI Elements (address bar) but nothing would happen. in almost all cases you could not hit F5/Control+F5/Control+R to reload. One had to close the tab.

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.
Sort of like hey you took 4th place at Olympics, but nobody talks about 2nd or 3rd place at the Olympics let alone 4th place let alone the people who got there.

Do the best that you can, be the best, be first.

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 that decided that they would change the Firefox Search Engine and hide the icon, and make it as painful as possible to switch the default search engine and refuse to talk about Transparency and User Feedback. Which arguably is probably the reason why Firefox is back where it was 10 years ago, back where it was 20 years ago when it lived under a different banner/name (10-26% market share). But that's completely and utterly unrelated and off topic.

[Sebastian Zartner]

On Thursday, January 29, 2015 at 5:31:34 AM UTC+1, Constrained Serenity wrote:

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.

You're complaining to the wrong people. You should better post to the Firefox DevTools team and provide some constructive and precise critique. General accusations that their tools are "useless" don't help anybody.
 

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.

The core of the Firebug Working Group is still the same (except me not being part of it anymore) with Honza as the head developer.
I don't know which ticket you're referring to and I can't speak for what's happening with the issues you open. Though if you believe it was closed by mistake, you should explain (in that issue) why it should be reopened.
 

They more or less carry very similar stances and arguments as the team...

Keep in mind that (with exception of Honza) those people are all volunteers spending their free time to improve Firebug. If you don't agree with their arguments, clarify your ones. Also some things may just not be implemented because of missing resources, so the best way to help out here is to contribute by providing patches.

Sebastian

[Richard Muse]

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,

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?

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.

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?

The spam of all the image and js requests. As a fully web app, we have a lot of images and various js pages that get loaded depending on the page and where the user is. Opening the main page gives me about 3 pages of network panel requests. the ones I wanted were in there when I started going line by line. I did see what every request was appearing twice. Not sure why that is. Your example was only in there once, but all the ones from our site are appearing twice, once as a zero KB and the same time as the real request. So having every entry twice did not help my spam problem. :) Will have to look into why we get double requests...

So linking back the real requests where we can use the console would solve the issue for the most part. As I just figured out, I can filter to XHR to get just the requests, so that helps as well. Amazing what might be there when the "easy" path suddenly gets ripped out from under you.

So not to say they are the same, but this is feeling a something like changing Windows versions. Part of the trouble is figuring out where what you need has been moved.

 

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

Ok, I see the problem I was having was the duplicated entries I mentioned before. It made it appear to "fail" to show results until I figured out which were the real entries and which the false ones. Then I saw the parsed results. So I can retract this one.

 

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.

As mentioned by myself and Constrained Serenity, it is not working. It just locks completely up. Open FireBug 2.0.7, cannot click anything, close it, page acts as normal. Latest Beta of 36 being used.

Sebastian

 

Richard

[Lawrence San]

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?

In the Net panel in Mac Firefox 34 / Firebug 2.0.7, the Search box just lets me highlight items in the list one at a time, but it doesn't ​actually filter (hide) the unwanted items. Is there some filtering trick I'm unaware of? Also the checkboxes associated with that search (like regexp) do nothing at all. That's why, when dealing with a large unwieldy list as I am currently, I'm forced to use Chrome's dev tools which actually do filter somewhat.

[Sebastian Zartner]

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,

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?

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.

As I said before, can you please kick off another thread regarding your issues with Firebug 2.0.7. This one relates to Firebug 3 and already get's quite vast.

On Friday, January 30, 2015 at 2:16:16 AM UTC+1, San wrote:

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?

The Net panel toolbar has buttons allowing you to filter by specific types of requests.

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:

Sebastian

[Lawrence San]

Oh... I already know about the filtering buttons; I didn't realize he was referring to one of them. I'm already filtering with the "Images" button. That works, but it's insufficient for my situation, because there's a humongous list of images on the page. I was referring to my attempts to filter further using the text-entry box, which in Firebug seems to be just search (highlighting one found line at a time). In Chrome's Net panel I'm able to type characters into the text-entry box and it filters on those -- narrows the visible list of images down to just a couple of items -- which I find much more useful.

[Sebastian Zartner]

Using the search field to filter the Net panel is already requested in issue 3560. And advanced filter possibilities were requested in issue 4829.

Sebastian

[Jan Honza Odvarko]

Some more comments to this thread.

I believe I understand most of the complaints and comments in this thread and I can assure you that we are (FWG and yes even Mozilla) listening to your feedback. I am personally involved in the Firebug project since 2007 and I am quite familiar with the whole thing. Not only with the code base, but also with various planning and strategies we have been through over the years.

Firebug in its current incarnation (i.e. Firebug 2) doesn't have any bright future (and believe me I belong among those who'd love to see it!). The architecture isn't ready for multi-process browser (aka e10s) and FWG is definitely not strong enough to refactor it. It would be enormous pile of work (estimated as several years of work by one of the FWG member). It's not something we want to spent time on - that would mean ignore built-in tools in Firefox and duplicate the existing platform. If you don't agree, do it yourselves. It's an open source after all.

Yes, Mozilla could base built-in tools on Firebug, but it didn't happen (I wasn't there personally when the decision has been made). Perhaps, sometimes it's just better to start over (it isn't an exception in the software world). But, this isn't even that important, the important thing is to make sure that Firefox has great developer tools - yes, even better than Firebug is now.

I agree that it still isn't the current situation - the more is important to work on one tool (and not spread energy on two independent tools). That's why we decided to move on and (re) build the next generation of Firebug on top of the built-in tools. There is good platform and bad UX and UX is exactly the thing where Firebug (team) can jump in and bring experience. Some features can be part of Firebug 3 and some can be implemented as built-in features for everyone's benefit. Some features can be developed as Firebug 3 features and if accepted well by the community of web-developers, we can make them built-in.

We are at a spot where we need to take this path. That's the best we can do.

If you want to be productive - point out concrete ideas. What specific features are you missing and what new features you'd like to have. File bugs [1]

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)

What should be the next?

Honza
(Firebug team leader)


[1] https://github.com/firebug/firebug.next/issues

[Jan Honza Odvarko]

On Wednesday, February 4, 2015 at 7:06:25 PM UTC+1, Jan Honza Odvarko wrote:

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)

Btw. Test with Firefox Developer Edition
https://developer.mozilla.org/en-US/Firefox/Developer_Edition

There is a bug in Nightly
https://bugzilla.mozilla.org/show_bug.cgi?id=1128870

Honza

[Jeremy Morton]

Of course, this all sucks huge balls for those of us who used Firebug in
SeaMonkey. But whatever, you don't care about us. Thanks a lot.

--
Best regards,
Jeremy Morton (Jez)

> --
> 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
> <mailto:firebug+u...@googlegroups.com>.

> To post to this group, send email to fir...@googlegroups.com

> <mailto: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/c5b43ea5-50ea-4647-9160-28803264223e%40googlegroups.com
> <https://groups.google.com/d/msgid/firebug/c5b43ea5-50ea-4647-9160-28803264223e%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Richard Muse]

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.

[Lawrence San]

I normally use the Firebug 2 debugger, but I've been comparing its behavior to that of Chrome and to the built-in Firefox debugger (all on a Mac, if that matters).

One thing I've noticed is the difference in behavior when you mouse over a variable in a line of code that's already been run. In Firebug 2, a little box displays right above the item you're hovering, showing its current value. This is great and I rely on it a lot. In Chrome, nothing shows when I hover. In the Firefox built-in debugger, sometimes something shows the value (plus often a lot of extraneous information), way off to one side so I have to hunt around for it... but often nothing shows, or the hover box gets "stuck" and won't update, or something. It's all too awkward to really use.

I haven't tried Firebug 3, but I hope its debugger hover behavior remains about the same as in Firebug 2. If it becomes almost unusable like the built-in Firefox debugger, that would be a huge step backward.

[Jan Honza Odvarko]

On Wednesday, February 4, 2015 at 8:08:43 PM UTC+1, Richard Muse wrote:

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.

Reported
https://github.com/firebug/firebug.next/issues/317

 

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!)

Heh, I need this one too! ;-)
 

2A. Work on the debugger which can slow to a complete crawl on large files.

This needs a platform bug report (bugzilla, https://bugzilla.mozilla.org/enter_bug.cgi), but as far as I know there are folks working on the underlying DBG API and constantly making improvements

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.

Reported
https://github.com/firebug/firebug.next/issues/316

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.

Good catch, reported
https://github.com/firebug/firebug.next/issues/315

Thanks!

Honza

[Jan Honza Odvarko]

Yes, I was thinking about the same, reported:
https://github.com/firebug/firebug.next/issues/314

Honza

[Sebastian Zartner]

Please stop using bad language!
As mentioned several times, the Firebug team has minimal resources, so the Firebug Working Group had to go that way, otherwise Firebug would have been dead as soon as e10s is enabled by default.

Note that SeaMonkey support for the DevTools is reported in bug 842942. So if you want Firebug to work there, you should vote on that bug or post a constructive comment or even provide a patch for it.

Sebastian

[Mahks]

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.

 I meant this list :

[GSTAR]

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.

[Jan Honza Odvarko]

On Friday, April 10, 2015 at 7:12:57 AM UTC+2, GSTAR wrote:

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.

This already works in Firebug.next, see this screenshot
http://snag.gy/ZNCr5.jpg

Please try Firebug 3 alpha 9
https://github.com/firebug/firebug.next/releases

Honza

[GSTAR]

I am using Firebug 3 alpha 9 and cannot see AJAX requests being logged in 'Console', they are only being logged in 'Network'.

[Cédric Simon]

Since today, Firebug 3.0 has dissapeared from my Firebug. I updated Firefox to 37.0.2 and Firebug 3 to alpha 10 but it doesn't help.  I also tried width a new profile. I'm under Mac OS 10.9.5.

[songy...@gmail.com]

My  Firebug 3.0 disappeared in the toolbar, too.  Firefox for mac 37.0.2 + Firebug 3 alpha 10+OS X 10.9.4. 

However, when I run Selenium + FirefoxWebdriver + Firebug 3 to generate HAR files, it show up in toolbar again.

Yui

在 2015年4月21日星期二 UTC+8下午5:47:23，Cédric Simon写道：

[Steve Storey]

I too have the same problem (albeit running Fedora 21 Linux) again with Ffox 37.0.2 and on a new profile. When running firefox from the command line, I do see the following messages, which look potentially relevant?:

1429648173958   addons.xpi      WARN    Error loading bootstrap.js for fir...@software.joehewitt.com: Module `resource://gre/modules/commonjs/sdk/addon
/bootstrap.js` is not found at resource://gre/modules/commonjs/sdk/addon/bootstrap.js (resource://gre/modules/commonjs/toolkit/require.js:24) JS Stack t
race: make/req...@require.js:24:12 < @jar:file:///home/steve/.mozilla/firefox/default.mn7/extensions/fir...@bootstrap.js:10:23 < @XPIProvider.jsm:4339
:1 < XPI_loadBoo...@XPIProvider.jsm:4339:7 < XPI_callBoo...@XPIProvider.jsm:4414:1 < AI_startInstall/<@XPIProvider.jsm:5826:1 < TaskImp
l_...@Task.jsm:330:41 < Handler.prot...@Promise-backend.js:870:23 < this.PromiseWa...@Promise-backend.js:749:7 < this.PromiseWalke
r.scheduleWalkerLoop/<@Promise-backend.js:691:37
1429648173959   addons.xpi      WARN    Exception running bootstrap method install on fir...@software.joehewitt.com: TypeError: this.bootstrapScopes[aA
ddon.id][aMethod] is not a function (resource://gre/modules/addons/XPIProvider.jsm:4442:8) JS Stack trace: XPI_callBoo...@XPIProvider.jsm:4442:
9 < AI_startInstall/<@XPIProvider.jsm:5826:1 < TaskIm...@Task.jsm:330:41 < Handler.prot...@Promise-backend.js:870:23 < this.PromiseWalker.w
alke...@Promise-backend.js:749:7 < this.PromiseWalker.scheduleWalkerLoop/<@Promise-backend.js:691:37
1429648173969   addons.xpi      WARN    Exception running bootstrap method startup on fir...@software.joehewitt.com: TypeError: this.bootstrapScopes[aA
ddon.id][aMethod] is not a function (resource://gre/modules/addons/XPIProvider.jsm:4442:8) JS Stack trace: XPI_callBoo...@XPIProvider.jsm:4442:
9 < AI_startInstall/<@XPIProvider.jsm:5841:13 < TaskIm...@Task.jsm:330:41 < Handler.prot...@Promise-backend.js:870:23 < this.PromiseWalker.
walke...@Promise-backend.js:749:7 < this.PromiseWalker.scheduleWalkerLoop/<@Promise-backend.js:691:37
1429648200743   addons.xpi      WARN    Exception running bootstrap method shutdown on fir...@software.joehewitt.com: TypeError: this.bootstrapScopes[a
Addon.id][aMethod] is not a function (resource://gre/modules/addons/XPIProvider.jsm:4442:8) JS Stack trace: XPI_callBoo...@XPIProvider.jsm:4442
:9 < shutdown...@XPIProvider.jsm:2185:13

[Mario Lorenz]

Hello Honza,

I agree with the previous writers: In Firefox 37.0.2 for Win, Firebug 3Alpha10 does not appear as a button. Also in the developer tools I can not change the Theme (Firebug is not displayed).

Regards,

Mario

[Jan Honza Odvarko]

I have released new version (a11) that should fix the problem

http://getfirebug.com/releases/firebug/3.0/firebug-3.0.0-alpha.11.xpi

(you should be auto-updated)

Let me know if it works for you now, thanks!

Honza

[songy...@gmail.com]

It works for me now (FF for mac 37.0.2).

在 2015年4月22日星期三 UTC+8下午5:39:41，Jan Honza Odvarko写道：

[Jan Honza Odvarko]

Great, thanks for the update.

Honza

[Cédric Simon]

Works for me too, thanks :)

Le lundi 10 novembre 2014 15:31:18 UTC+1, Jan Honza Odvarko a écrit :

http://bit.ly/1wKR16L

Honza

[GSTAR]

As advised, this is not working for me. I have tested with alpha 12.

Test case: http://www.sportinglife.com/

Type in to the search field on the top right. The AJAX request only appears in the Network tab and not in the Console tab.

[Sviatoslav Bulbakha]

Can't get it working on both 37.0.2 and 39.0a2.

DOM panel is visible only on first start after installing. And then all Firebug features (except theme) disappears.

On Monday, November 10, 2014 at 10:31:18 PM UTC+8, Jan Honza Odvarko wrote:

http://bit.ly/1wKR16L

Honza

[GSTAR]

Should we post bugs in this group or on Github?

[Jan Honza Odvarko]

On Monday, May 18, 2015 at 6:08:03 PM UTC+2, GSTAR wrote:

Should we post bugs in this group or on Github?

Github please!

https://github.com/firebug/firebug.next/issues

Honza
 

[Rhagni Oliveira]

I miss Cookie tab :(

Em segunda-feira, 10 de novembro de 2014 12:31:18 UTC-2, Jan Honza Odvarko escreveu:

http://bit.ly/1wKR16L

Honza

[Shockbeton]

Please make persistence consistent. The Console has a nice "Persist" toggle, but to persist Network data, for example, I, apparently, need to set a general setting in Toolbox Options to "Enable Persistent Logs" which doesn't seem to do what I want it to, persist the freakin network data.

[Porcupine]

Cookies can be viewed under the Storage tab.

[Porcupine]

The Storage tab is severly limited for me, because Local Storage only shows 50 items or so. My web-app uses many more.
Now that we do have a nice feature to view and edit storage, it is too limited for me to be useful. :-(
Is this an issue that Firebug can solve, or is it something that is entirely for the Firefox team?

What I would like in the storage interface is the ability to view at least a few thousand items, plus the ability to sort & filter on keys and values.
Would that be possible?

Thanks!

[Sebastian Zartner]

That's something that needs to be fixed within the built-in DevTools. You may create a bug report for that.

Sebastian

[Sebastian Zartner]

The Enable Persistent Logs option does persist the requests within the Network panel. I.e. on page reload the new requests are appended and listed under the ones from the first request.
Anyway, I agree it would be nice to have a button for that within the Network panel. This is already reported in issue #206.

Sebastian

[s...@joyceinc.com]

The latest update I can find for Firebug 3 is from April.  Where can we get the latest version?

[Sebastian Zartner]

Version alpha 12 from April is currently the latest published version. If you want the newest one, you can get the source code from GitHub.

Sebastian