I believe all the current development tools do it wrong, and the right place for a tool is outside the browser, as a custom shell around the main browser component.
This is how I tend to work: I load up an app. I set up my credentials (by logging in or setting a particular cookie manually, for example). I debug using Firebug, mainly using the DOM view, the console and the JavaScript REPL. Then I might change my credentials to see the page as a different user, for example. I clear the cache now and then, and I clear my cookies often. I also change things like cookie preferences and turn JavaScript on/off to see how my app behaves. I also work on multiple projects concurrently, so I frequently need to switch, meaning yet again to clear the browser state.
In other words, I need the browser as a clean slate. I frequently need to throw its state away, and I rarely if ever run pages as "myself".
I'm a Chrome user, so for this reason I currently use Firefox as my dedicated debug browser. This means I can always throw away my browser state, and I can close Firefox when I'm done with work. Firefox is a resource hog on OS X, and will frequently sit consuming 5-10% CPU even when idle, so this is actually important. I almost never use Chrome for debugging, not just because its DOM view and console are both much worse than Firebug's, but because it's my browser. (Yes, I know that Chrome supports per-window profiles, but Chrome just isn't good enough for debugging.)
My ideal development tool would be a thin shell around a web browser component. It would be chock full of techy dev stuff, and it would not compromise the dev aspect in favour of user-friendliness; unlike today's browsers, everything could be provided natively by the tool instead of inserted awkwardly by "extensions". It would do away with user-facing features like browser extensions, fancy history and bookmarks. In other words, it would be a hard core, bare-bones development tool.
This tool would support "projects"; each project being is a browser window, and each browser window is logically compartmentalized, with its own cookie database, history, settings, etc., with the option to save certain things like cookies, so that I can "bake" current browser state and recall it later. The ideal solution would be for each window to be able to embed different browser engines; there is no particular technical reason why this should not work, although it would be a little more work to implement.
I actually started writing an app like this for OS X that embeds WebKit. It was surprisingly simple, and I got a decent DOM inspector view and style editor working, but then my mind wandered off to work on something else. I may pick this project up again at some point.
Prism used to be kind of cool but Mozilla abandoned it. There also used to be more focus on being able to build arbitrary tools around Gecko but Mozilla abandoned them (except for specialized OSes?).
Gecko is my favorite layout engine and Mozilla makes my favorite browser environments. Firefox gets weirder and weirder sadly.
The multiproject browser environment thing sounds really cool. Multifox does some of that but its interface strikes me as a bit awkward.
Just so you know, Firefox does allow you to run multiple profiles simultaneously in different instances. I do this all the time. Just "firefox -a blark -P profile_name" (or -ProfileManager) and there you go. Don't know if it will work on OS X though.
It's also possible to preload plugins, config settings, and extensions so that you don't have to set them up each time. Let me know if you'd like some pointers. This was a big part of my work at a previous job.
You should, I like that idea very much.
I was also having a similar problem with mixing work & personal data. Now I am using Canary as development browser, that itself is enormous resource hog.
If you will continue working on such a project I am happy to help!
It's small usability issues more than anything specifically missing. Some things off the top of my head:
* The "point to find in DOM" icon is tiny and squeezed in between other icons at the bottom of the page. It's one of the most important tools, imho, and it can't be tucked away like that. And it needs a keyboard shortcut to toggle it.
* The "point to find in DOM" is very flickery and just feels more shoddy than Firebug's. Firebug uses a rectangular border, which I think makes more sense than a colour overlay which obscures the content.
* The DOM tree view is gnarly; by which I meant that it's cramped, squeezed together, hard to edit and navigate, and just generally feels like one is fighting a jungle of vines and branches. It needs more spacing and more a consistent editing mode. Firebug's isn't great, either, but it's more spaceous.
* The CSS style view is also pretty gnarly in Chrome. The hit area for the checkbox to enable/disable a property is tiny, for example, and the overstrike is black, whereas Firefox wisely grays out disabled items. Chrome uses these dividers which are completely unnecessary given the source information on the right.
* The action to add a property is to click somewhere inside the CSS view that is not text. Yes, to click. It makes no sense, norwhere in any user interface do you add stuff by clicking in empty space. Firefox more wisely uses double-click, even if that's not great either, but at least has some precedence in GUI history.
* Chrome has no tools to add styles. Firefox has a right-click context menu for CSS properties allowing me to right-click somewhere and select "New property" or "Add rule".
* Chrome: The icons in the lower bar change depending on which tab (Element, Resources etc.) you're in. Pretty confusing since some of the icons apply to the tab you're in, and some are always enabled (like the "point to find in DOM" button).
* Firebug shows in this case all the CSS information I need for the element. Chrome is information-poor in comparison.
* Chrome has inserted a useless "element.style" entry which is unnecessary unless you actually want to add style to the element; for inspection purposes it's superfluous.
* Chrome also wastes a whole line for the "computed style" part, which Firebug wisely tucks away in a tab.
* Chrome wastes the whole lower line on the DOM path, which I personally never use. In Firebug it's part of the DOM view and doesn't affect the CSS view.
Here's an improvement suggestion I'm surprised nobody has thought properly about. One thing I often need to debug is the flow between pages. For example, in some web app I click a "Login" link, get a login page where I edit stuff, then click "Log in", then the server does a few redirects and finally gets me to the "you're logged in" page. Now, Firebug and Chrome both have a "persist" mode for the network view which allows one to see the sequence of pages being requested, but since it's a strict log and mixes different content it's very hard to read, and very hard to figure out the true flow of events from. Here is such an exchange: http://i.imgur.com/aCs8pmF.png. To get it I had to select the "Document" and "Other" event types. But I have to spend 10x as much time analyzing this than if I simply go to Firefox and turn on the stupid but effective "Live HTTP Headers" add-on and then copy everything into a text editor. The HAR is too cooked to give me a proper bird's eye view.
Truly what I wish for is some kind of graph that's page-oriented. Here is a very quick Illustrator mockup: http://i.imgur.com/pQqOtPX.png. Obviously hovering/clicking on various elements would let you look at headers and what not. The idea is really a persistent timeline with a certain history, and which presents a logical view of browser navigation. It's important here to distinguish between user actions and stuff done by the browser (redirection, AJAX); it's important to know when something contributed to a page render or was just one link in a chain of redirects.
Again, I could go on, but I have better things to spend my evening on. :-)
This is how I tend to work: I load up an app. I set up my credentials (by logging in or setting a particular cookie manually, for example). I debug using Firebug, mainly using the DOM view, the console and the JavaScript REPL. Then I might change my credentials to see the page as a different user, for example. I clear the cache now and then, and I clear my cookies often. I also change things like cookie preferences and turn JavaScript on/off to see how my app behaves. I also work on multiple projects concurrently, so I frequently need to switch, meaning yet again to clear the browser state.
In other words, I need the browser as a clean slate. I frequently need to throw its state away, and I rarely if ever run pages as "myself".
I'm a Chrome user, so for this reason I currently use Firefox as my dedicated debug browser. This means I can always throw away my browser state, and I can close Firefox when I'm done with work. Firefox is a resource hog on OS X, and will frequently sit consuming 5-10% CPU even when idle, so this is actually important. I almost never use Chrome for debugging, not just because its DOM view and console are both much worse than Firebug's, but because it's my browser. (Yes, I know that Chrome supports per-window profiles, but Chrome just isn't good enough for debugging.)
My ideal development tool would be a thin shell around a web browser component. It would be chock full of techy dev stuff, and it would not compromise the dev aspect in favour of user-friendliness; unlike today's browsers, everything could be provided natively by the tool instead of inserted awkwardly by "extensions". It would do away with user-facing features like browser extensions, fancy history and bookmarks. In other words, it would be a hard core, bare-bones development tool.
This tool would support "projects"; each project being is a browser window, and each browser window is logically compartmentalized, with its own cookie database, history, settings, etc., with the option to save certain things like cookies, so that I can "bake" current browser state and recall it later. The ideal solution would be for each window to be able to embed different browser engines; there is no particular technical reason why this should not work, although it would be a little more work to implement.
I actually started writing an app like this for OS X that embeds WebKit. It was surprisingly simple, and I got a decent DOM inspector view and style editor working, but then my mind wandered off to work on something else. I may pick this project up again at some point.