Firebug and DevTools Integration

https://hacks.mozilla.org/2015/10/firebug-devtools-integration/

by _jomo • 11 years ago

129 36 11 years ago

hacks.mozilla.org

vital3• 11 years ago

Cookie editing is still missing. Without this feature a wider adoption of FF dev tools or its full utility as a wedev tool is impossible. Yes, I voted for https://bugzilla.mozilla.org/show_bug.cgi?id=1031192. Please do the same. Thanks.

pepve• 11 years ago

You can edit cookies with the "Developer Toolbar". It's under "Tools -> Web Developer" and reachable with the shortcut "Shift+F2". It's not brilliant but it works well.

awalGarg• 11 years ago

I second that. The GCLI is pretty awesome. It is a huge work in progress but still works pretty neat.

Here is the entire documentation: https://developer.mozilla.org/en-US/docs/Tools/GCLI#Commands (links to list of commands, I suggest reading the entire page).

The best part is that it is extensible (Scratchpad FTW!) :)

vital3• 11 years ago

Nice! Thanks. New to me. Still, considering how "not brilliant" this feature is, I'd rather use Chrome dev tools when cookie editing/deleting is needed.

jakub_g• 11 years ago

You can use https://addons.mozilla.org/en-US/firefox/addon/cookies-manag... which has a great UI for editing cookies, and the permanent search filter that will limit shown cookies to the matching domain(s)

vital3• 11 years ago

Thanks. I'd rather use Chrome dev tools for now.

canuckistani5• 11 years ago

Thanks for voting - I agree this is a critical gap but I have high hopes to get it fixed very soon.

yeukhon• 11 years ago

Firebug is like steel so heavy to use. Once I have accumlated enough logs the tool just starts lagging. Devtool is awesome but definitely still lack of some nice touch. I think there are still so much to improve with browser-side devtool. One annoying thing is (regardless of which browser, which devtool), editing stuff always happen in a small portion of a screen. If we can have a dedicated devtool app that'd be awesome. Bigger font, more tabs, drag and drop placement / customized view), and with extension (You should be able to do that already, don't remember).

Sure you can drag the devtool out, but it still lives as part of the browser windows, and switching back and forth between several instances of browser windows? tough! I am not sure, but has Mozilla hired the folks behind Firebug already?

canuckistani5• 11 years ago

Jan Odvarko, the author of this post, is a Mozilla employee working on Firebug and related projects. He has worked for Mozilla for 4+ years and is paid to maintain / improve Firebug.

hartator• 11 years ago

Firebug 3 is not another developer tool, it is rather a thin layer built on top of DevTools.

Why I feel it's terrible news?

I feel like this is a promise of less features for more bugs without any clear vision about why Firebug should be ditched in favor of DevTools.

canuckistani5• 11 years ago

Here are two articles from last year articulating Mozilla's view on Firebug:

https://hacks.mozilla.org/2014/12/firebug-3-multiprocess-fir...

https://hacks.mozilla.org/2013/10/firefox-developer-tools-an...

frik• 11 years ago

Firebug has several little features that aren't available in FF DevTools nor Chrome DevTools. Let's hope Firebug 3 has no feature regression and stays around.

canuckistani5• 11 years ago

Which ones? Curious :)

symlinkk• 11 years ago

There is no reason to still use Firebug in 2015 besides laziness.

talideon• 11 years ago

In what regard?

smallarmsdealer2• 11 years ago

Chrome is not the world, pal.

Firebug inspired all the current tools and it's great to see them still contributing to Mozilla's fight for the open web.

If you're supporting the Gecko rendering engine, using a tool to debug it is not laziness. Treating Chrome as the only game in town is laziness.

function_seven• 11 years ago

I think parent was talking about Firebug vs. the native Dev Tools. Nothing to do with Chrome.

jMyles• 11 years ago

I still can't seem to view websocket frames with DevTools. It's the only thing I switch to Chrome dev tools for. Am I alone?

ndesaulniers• 11 years ago

https://bugzilla.mozilla.org/show_bug.cgi?id=885508

canuckistani5• 11 years ago

Platform support has landed in Firefox 44 and we're working on a prototype extension: https://github.com/firebug/websocket-monitor

Soon!

bigethan2• 11 years ago

I've started developing in FF because of the ability to not have all my chrome plugins installed everywhere, and the dev tools are pretty much there compared to chrome a few versions ago.

For performance inspection chrome is still the winner for sure, but when I just want a light fast experience, FF has been great the last few months.

peterjmag• 11 years ago

Can you expand on that first point? Do you mean that you'd prefer that your Chrome extensions not sync across different machines? Or that you just use a different browser when you want to work without a bunch of extensions enabled?

For the latter, you can create a new user[1] and switch to it for a different set of extensions or none at all, or you can just use an incognito window.

[1] https://support.google.com/chrome/answer/2364824?hl=en

pasbesoin• 11 years ago

Or, you can run Chrome(/ium) using a different profile subdirectory. Relevant commandline option:

    --user-data-dir=/home/owner/.config/alternative-directory

(It's slightly different under Windows.)

danso• 11 years ago

I second the mentioning and advocating of this feature. For my main Chrome user, I have StayFocusd installed, and its workings make themselves known in various debug outputs, so I switch to a stub user setup on Chrome when doing dev work. I also switch the theme so that I subconsciously associate the non-logged-in, green-colored browser with "hey, it's work time". On a separate user instance, I'm logged into Facebook but have otherwise thrown away the password...it's amazing how the friction of a simple clicks (it only takes a right-click to pop-open the available Chrome users, then left-click to select one) can almost by itself break the reflexive whim to check social media accounts.

bigethan2• 11 years ago

Sure! For "I'm a person who is also developer" browsing I have a variety of plugins installed that play havoc with the console normally. In FF I have "I'm working" plugins installed.

I'm aware that I can have different user, but I enjoy the ability to alt-tab obviously based on intent (FF is _always dev, not sometimes dev, sometimes life, or a collection of incognito windows that I then have to alt-~ through).

Though I'm weird about my browsers :-) I use Fluid "apps" (http://fluidapp.com/) for pretty much every site that I visit regularly and BrowserFairy (http://www.browserfairy.com/) to correctly send me to the correct "app" when clicking links.

neals• 11 years ago

What really bother me with Firebug and Firefox-debugging is that I can't see when the debugger pauses my page.

So when I'm testing and the debugger fires, I'd still be clicking stuff on my page, wondering why it isn't responding.

Touche• 11 years ago

I just checked and Debugger -> Sources is still a single alphabetical list. This makes it unusable on a non-trivial JavaScript app that will easily have 50+ modules.

zspitzer• 11 years ago

there is a bug for this, please vote for it

Display the script sources in a collapsible folder tree rather than in a list

https://bugzilla.mozilla.org/show_bug.cgi?id=987685

inanutshellus3• 11 years ago

I keep an old copy of Firefox around just so I can have Firebug 2.

Here's what I'd like DevTools to do:

* Make a breakpoints view, not one embedded into a massive list of unsorted (or sorted-by-load-date I guess?!) files that changes over time. If that can't be done (or is against the design philosophy of DevTools), letting me choose the sort order would be nice (e.g. recently-viewed files first, or files with breakpoints, etc ..... and uh, remembering those files and/or settings through refreshes would be fantastic... I miss it from Firebug 2). It's nice because after/during refreshes the breakpoint view lets you pull up the file the second it's loaded, instead of scrolling around in the file list until you find it.

* Make it a LOT more obvious when DevTools is stopped at a breakpoint.

* DevTools doesn't handle initial focus the way Firebug does. As in, when you pull up Firebug via the selection icon--oh, DevTools needs that selection icon for the toolbar--it goes straight to the dom node you selected.

* Make DevTools stop crashing. It stops working. Constantly. The console will just stop printing output, and the DOM view just stops displaying HTML, requiring a browser restart. (When this happens, if you, say, pull up the console and type "1" and hit enter, usually the console echos "1" back to you. When you're in this state, it's not echoed back, though, oddly, some script messages still pop in.)

* Make "debugger" start working again. There are some places where--for who knows what reason--both Firebug and DevTools have ignored breakpoints I've put in, and I've been able to get around it in Firebug by explicitly putting in "debugger;" into my code. You definitely know you're in deep kimchi when you need "debugger;".

* Make DevTools remember the state of my "Log Response/Request Bodies" checkbox. It gets reset constantly, and it should be remembered across refreshes. Heck, even by URL. If I turn it on, leave it on.

Also, for one of my websites, it can't load the source. It just shows "eval" as the filenames over and over with nothing in them. Firebug 2 loads it just fine.

Long live Firebug 2!

gear54rus• 11 years ago

There are some places where--for who knows what reason--both Firebug and DevTools have ignored breakpoints I've put in...

This might be because the js file you put them in is loaded with another URL and is therefore considered a different file (and therefore does not have your breakpoint). This is what I've experienced before.

This is a bs design, of course, and files should probably be compared via means other than URL.

inanutshellus3• 11 years ago

Sure, I get it, but when it happens you're just in a bad world and you can either try to put breakpoints in every copy of the file that Firebug/Devtools detects, or you can say *&$% it, and add "debugger;" in the file.

inanutshellus3• 11 years ago

Oh, and DevTools doesn't honor my breakpoints. They "slide" down to the next line DevTools thinks it can actually stop on.

For one thing, the number of times it "slides" past valid code is shocking. Right now I'm looking at a perfectly boring JS file and the breakpoints are only stopping on the function declaration lines. The contents of the functions are being slid past. Once I restart my browser they'll work again.

For another, as a time-saver I put breakpoints on lines that /will/ be valid when I refresh (saves me from having to refresh the file twice), so it simply doing as I told it to do would be grand.

EdSharkey• 11 years ago

Thanks Mozilla, exciting developments! I really enjoy the Firebug user experience, and am looking forward to having it be the frontend to the developer tools.

Firebug and DevTools Integration

Related Stories