Opera has posted what looks like a great new Web debugging tool Opera Dragonfly which is released in alpha.
Debug JavaScript, inspect CSS and the DOM, and view any errors – Opera Dragonfly makes developing using Opera easier than ever, both on your computer and mobile phone.
Shawn Lauriat has a nice write-up that tells the story:
It offers most of the familiar tools for DOM inspection (along with a nice DOM editing capability), error logging (with the same granularity as before wrapped in a more polished UI), a JavaScript debugger that rivals WebKit’s Drosera, a JavaScript thread logger, and a lot more that I haven’t explored yet.
Time will tell whether Dragonfly can get enough developers to use Opera and keep them there, and how much the developers behind the new developer tools listen to the community in the coming iterations, but so far this looks extremely promising.
Features
Reach breaking point step by step: Opera Dragonfly’s fully featured JavaScript debugger makes building sophisticated Ajax applications easier than ever. Step through your code line by line, setting break points along the way. This allows you to make sure your application and scripts are acting as you designed them.
Redefine your style: Its not just the DOM you can inspect. Check out what CSS rules apply to which element, and what rules are inherited or set by browser defaults. Overridden rules are highlighted so you can see what styles are or aren’t applied. Support for editing CSS rules will be added in an upcoming version.
Spot your errors: An improved error console allows you to see, filter and log any errors in your scripts, pointing to the exact position the error occurred. Use this in combination with the other tools to hunt down and fix your site’s bugs.
Debug the DOM: View source isn’t much use if you use DOM Scripting to alter the DOM. Opera Dragonfly allows you to inspect the updated DOM and all it’s properties. Support for editing the DOM will be added in an upcoming version.
The features that are not there yet, but are upcoming, include support for editing of CSS, JavaScript and the DOM, a single window mode, improved JavaScript thread handling, XHR and HTTP monitoring, improved keyboard navigation, and translation into a number of languages.
Mario Heiderich of Ormigo has created a jQuery based code snippet/bookmarklet that is capable of detecting floating errors and adding a dotted orange border to elements which should be cleared - but aren't.
It saved me a huge bunch of time debugging complex layouts for all browsers - especially IE6. If jQuery isn't already loaded on the page it can easily be fetched with the several jQuerify approaches.
A new alpha version of Firebug 1.2 is available for testing. It has several performance improvements, and some new UI. Give it a go and report any issues.
Also, ChromeBug takes Firebug into the world of debugging full Firefox extensions. It depends on the alpha of Firebug 1.2 and once installed you can boot it up via:
Thierry Parent has released a new version of TraceTool, his open source tracer program, with a JavaScript client.
The javascript TraceTool API is a cross browser (tested under Internet Explorer 6, Internet Explorer 7, Firefox 2 and Opera for mobile) and cross domain tracing solution (maybe the first one). The viewer can be installed on any windows PC (localHost for example) while you are displaying a page from another server. Debuging a Web page from your mobile is very easy. Just configure the TraceTool JavaScript client to use the viewer on the network.
To allow sending traces to another server as the original page (Cross domain communication), the API does not use Ajax (Single domain) but dynamic script creation. Traces are encoded and passed in parameter to the viewer. Large trace messages are split into multiple scripts.
With this API , you can send simple traces, objects , dump, call stack, manipulate traces (sub traces, delete, append,...) and more.
An ideal complement to firebug and a great enhancement to IE debugging with one API for Java, JavaScript, .Net, Delphi, C++ and ActiveX.
Jan Odvárko "missed two movie nights" to create cookie support in Firebug. His Firebug plugin, Firecookie, gives you access to view, search, create, remove, and manage the permissions of a cookie, all from within a Firebug tab.
Firecookie creates a log entry every time when a cookie is created, changed, deleted or rejected (an option you can change).
He has also written a nice tutorial on extending Firebug. It is great to see sub-plugins for Firebug such as YSlow, Firecookie, etc. Do you know of any other good ones?
NOTE: There are, of course, separate Firefox plugins for cookie management.
I have talked to a few people recently who keep Firefox 2 around just "because Firebug needs it" but the latest beta works great in Firefox 3 (which I find to be a huge leap on the Mac).
for(var i = 0; i <names.length; ++i) window.console[names[i]] = function(){};
}
I would love to see a window.console API based on Firebug standardized so it can just be there. But then this code will still be around for pre-browsers.
We all talk about Firebug, which is a fantastic tool for debugging, but there are some others out there. WebKit comes with Drosera, which until now has been hard to get going on Windows (you could build from source).
Our JavaScript debugger Drosera is available in the Windows nightlies, and I would love to get some help testing and finding issues. Drosera will not work with the Safari beta, but should automatically connect to the nightly it's downloaded with. Simply use the run-drosera script that's now included. I'm excited to bring Drosera to Windows and I hope it becomes a go-to tool for your Windows JS investigating, testing, and development.
Do you care? Are you on Windows and have been jealous of the Apple debugging love?
Firefox used to be the lean mean fast browser. Well, definitely fast. People flocked to it, in part, due to its speed. These days it seems like it is falling back and people are jumping on WebKit nightly, Opera, and even IE 7 as faster alternatives.
Mozilla is a little flummoxed by the birds memory appetite, and is going on a crusade to hunt down the issues, which are even more of an issue in mobile.
Stuart Parmenter, a Moz developer, has been doing some painful hard work for us. He started out discussing the memory fragmentation issue:
I've been doing a lot of work trying to figure out why after loading a lot of pages much of your memory seems to disappear. I've tested all sorts of things -- disabling extensions, plugins, images, etc. I've run leak tools over and over looking for things we might be leaking. Occasionally I'll find something small we're actually leaking but more often than not I don't see any real leaks. This lead me to wonder where our memory went. Firefox has a lot of caches internally for performance reasons. These include things like the back/forward cache (which helps speed up loading pages when you hit back), the image cache (keeps images in memory to help load them faster), font cache, textrun cache (short lived, but used to cache computed glyph indicies and metrics and such), etc. We also introduced in Gecko 1.9 the cycle collector which hopes to avoid cycles in XPCOM objects that we might hit. We've also got the JS garbage collector. All of these things mean we could be holding on to a bunch of objects that could be taking up space so we want to eliminate those from the picture. I released the RAMBack extension earlier this week which clears most of these things.
So, if it is none of these things, what is going on? Why after a while do we end up using more memory than we should be if we aren't leaking and our caches are clear? At least part of it seems to be due to memory fragmentation.
At this point he tests the browser by opening up the browser on certain sites and taking them off. He then takes a peek at the heap:
Knowing that someone is actively working on the issue is psychologically huge, so kudos to Stuart for sharing some of his initial findings, and good luck hunting!
Jean-Fabrice Rabaute, author of Companion.JS, has put out a new DebugBar as he aims to get IE developer tools on par to Firebug.
In this new version, on a selected element in the DOM Tree, the DebugBar can now display source code, applied style (with css details), computed style, layout, and attributes.
I got to spend a little time with Steve Souders, Chief Performance Yahoo!, and not only is he a really good guy, he has a lot of great experience at getting web sites performing.
I have a full writeup of his talk on Web Performance where he discusses his 14 rules of performing sites, how the frontend web code really matters more than you think, and how the browser cache isn't helping us out as much as we would like to think.
I discovered that resources (scripts, stylesheets, images) read from the browsers cache (with no HTTP traffic) still show up in Net Panel. This has caused confusion when people thought their cacheable components were not actually being cached by the browser. I talked to Joe Hewitt and settled on a fix that comes with this version of YSlow. The full details are found in the article Bug (fix) in Firebug's Net Panel.
, Opera
