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 > <https://www.google.com/url?q=https%3A%2F%2Fwiki.mozilla.org%2FElectrolysis&sa=D&sntz=1&usg=AFQjCNG8t8sJZzH3ci8i5zma8Zl-KVGB5Q> > > 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 > <https://bugzilla.mozilla.org/show_bug.cgi?id=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 > <https://github.com/firebug/firebug.next/issues/new>. > 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. > > 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 > <https://getfirebug.com/wiki/index.php/Firebug_Terminology#DOM_Panel>, > 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 > <https://code.google.com/p/fbug/issues/detail?id=4173>, though. You may > want to create an issue for re-adding the property path > <https://github.com/firebug/firebug.next/issues/new>. > > >> B) Vertical panels, is this to be available in 3? >> > As far as I can see not yet. Worth a new report > <https://github.com/firebug/firebug.next/issues/new>. > > 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' > <https://github.com/firebug/firebug.next/issues/new> 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 > <http://blog.getfirebug.com/2014/11/10/firebug-3-next-generation-of-firebug/> > . > > 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=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 > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/7d070eb5-74e6-4f42-bb15-070ad1344fbd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
