TODO: it needs more work, but I just don't currently know anymore when it comes to this topic.. Maybe someone smarter can chime in here.
NOTE: removed erroneous note regarding the use of maxCalls. Disconnection does not imply removal of joinpoints.
Today's browsers are notorious for memory leaks, and there are lots of speculation and confusion about the issue. Most of the memory leaks have to do with JS interacting with the DOM. Specifically here we want to talk about Dojo, and what it does to help with memory leaks.
Dojo does it's very level best to clean up after itself, and part of that is keeping itself in 1 namespace (dojo.*).
event system cleanup
One of the big memory leak areas on IE browsers is in the dojo.event system. When you build dojo.event.connect() calls to DOM nodes that you then erase, the connected function may be leaked through the Node's context. Dojo's solution to this problem is straightforward and battle-tested. If you use dojo.event.browser.clean(domNode) on the domNode you need to remove from the DOM, it will clean up the connect calls, and let the Garbage Collector decrement the reference counts to the function correct. dojo.event.browser.clean() is basically a non-op on non IE browsers, so it's safe to do all the time. Plus, it is good about children nodes, so you don't have to worry about any children of the domNode you erased. Obviously, this would be onerous to require you to use manually everywhere, so Dojo automatically cleans up everything in the visible DOM tree when a page unloads and also when widgets are destroyed. Knowing how to use dojo.event.browser.clean() can help you in cases where you might not be relying on the widget system for Ajax updates of part of a page, though.
IE and Memory leaks.
IE is known to not be very keen on memory useage and DOM manipulation. http://home.wanadoo.nl/jsrosman/ is a useful tool to help track such evilness down. More understanding of IE memory leaks can be found http://javascript.crockford.com/memory/leak.html here.