Firebug and DevTools Integration
hacks.mozilla.org
hacks.mozilla.org
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?
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!) :)
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!
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.
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.
Soon!
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.
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.
--user-data-dir=/home/owner/.config/alternative-directory
(It's slightly different under Windows.)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.
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.
https://hacks.mozilla.org/2014/12/firebug-3-multiprocess-fir...
https://hacks.mozilla.org/2013/10/firefox-developer-tools-an...
https://hacks.mozilla.org/2013/10/firefox-developer-tools-an...
So when I'm testing and the debugger fires, I'd still be clicking stuff on my page, wondering why it isn't responding.
Display the script sources in a collapsible folder tree rather than in a list
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.
Unix is about lots of tools coming together and so is the internet - if you don't like a tool fork it or go use something else. I don't understand grandstanding about it being antiquated or sucking when others find it useful and appreciate the development efforts.