I think this problem has no solution other than building lighter pages; for example, if you have big datagrid table you could adopt some kind of pagination or build your pages using block elements instead of tables...

I ran into the exact same problem. #1 mb.container does a hide function by default. What happens is that as you continue to open containers the others still remain in memory. The solution I found is very strict.

(1) All code must be in correct order. Meaning in-line css before scripts and before external css. Both CSS's before javascript. External javascript before internal. And most important, all javascript in head. Like 99% of it. I have discovered document flow is WAY WAY WAY more important than anyone ever thought it was. It is like a hard drive that needs a defrag. If your code is scrambled your results will be too. The DOM operates like a hard drive in the fact that it executes in a specific order, if everything is out of order, then "ONLOAD" or even RUNTIME (Meaning the execution of live javascript at client side) the DOM is literately jumping back and forth between digital memory gates gathering the information it needs to execute your request. I mean, it is all one's (.6 to .8 Milli volts) and zero's (.2 to .4 Milli volts) whether it is a hard drive or a memory. We are not use to the idea of needing to organize memory because when our hard drive extracts the information we need, it naturally piles up in memory in the correct order that we need it to be in. However, download a web page is the exact same science. Except that there is no method to fix, or re-align the information into our memory that we need it to be in. So, it is up to 'US' as developers to make sure what we are sending is straight, in order, and clear. The issue that I find with most browsers is that it is NEVER the browser in the end. It is something I did not do!!! For example, Place 2 div's 1 inside the other. Make the parent with padding:10px and the child with zero. Place one more div inside again with a padding of -10px and go look at it on 8 different browsers and see what happens. the reality is that the "Better Browsers" are actually fixing your mistakes for you without telling you. (Smarter browsers) Browsers like chrome take your code exactly as it sees it and renders it as is without fixing it for you. I have news for everybody... IE? Just not that smart is all.

The problem is that every time you close the memory still contains the previous document even though you don't see it any more. Even if you replace mb-containers hide function with a remove function you still have the same problem after time if your document is not in proper order allowing the browser the head room, to in a sense, defrag its self making room for new items entering the DOM space.

What I did to solve the problem was organization of the document, as well as making all containers called via AJAX as well as their content. Along with changing the close to a remove function. now every item entering and leaving the DOM is fresh with plenty of organized room (Browser RAM) and when leaving, (Close) is not leaving a clutter when removed because the document is tight to start with. (you know, like deleting something off your hard drive causing fragmentation? If the document being deleted is not fragmented to begin with then neither is the empty spaces left behind when deleted.) As you know, fragmented spaces to save to makes for a long disorganized save. First available space is always used up first. Your DOM is doing the same thing with it's memory. this is why as you use it, it gets more sluggish as time goes by. It gets to the point that to save a single item to the DOM memory space that it finds its self doing thousands and thousands of calculations to figure out how to save this new item.

So, answer, CLEAN SPACE IN, CLEAN SPACE OUT! All up to the developer because your browser was not designed to support this load to begin with. AJAX is already causing the browser software developer's to go back to the drawing board! Knowing them they will write some routine to handle the disorganized mess we create for us, create some kind of AJAX memory handler that does for us what we should already be doing. The ones that do, we end up calling the better browsers and the ones that don't we call the lousy browsers when it is all our own faults to begin with. Yesterday, today and tomorrow. IE is no exception.