One common issue that extension developers have is how to maintain state between different windows throughout the lifetime of Firefox (or another application) even while the windows are opened and closed. Once a window is closed, all of its context and state goes away.
The typical approaches are to use an XPCOM component, which can be maintained throughout the application lifetime, but is a bit unweidly to write. A second technique is to use preferences, however they persist even after the application is closed and aren't the most logical way to store temporary state. A third technique is to use the hidden window. Mozilla uses a hidden window because the XUL architecture requires a window to be available to show the menu bar on Mac even though no windows are visible. Storing data on this hidden window is what is officially known as 'an evil hack'. These three techniques are described in more detail in Working with windows in chrome code.
There are some other ways to accomplish this, at least to some degree, like using the persist attribute, RDF or other XPCOM services, although none are really designed for this purpose. What's needed then, is a proper means to store state while the application is running.
Luckily, the WHAT-WG's Client-side session and persistent storage (sometimes called DOM Storage) mechanism can be used, with some small enhancements suitable for extension use.
Right now, there are two types of storage available, 'session' which stores per-window data (actually per-tab of course), and 'global' which stores data to disk permanently (at least until the user deletes it). I propose a third type, called 'application' which behaves the same as the global storage but lasts only until the application exits.
I also propose extending the per-domain storage mechanism to support chrome URIs, identified by names such as 'chrome://packagename'.
For details about this proposal, see XUL Persistent State and Observers. I also provide a specification for the existing XUL broadcaster/observer mechanism and how it might be extended to support observing changes to a storage area.
Thoughts?
Also, I should point out that the proper name is 'Client-side session and persistent storage' not 'DOM Storage'. It doesn't have anything to do with the DOM, and is easy to confuse with the 'Storage' system used in Mozilla which stores data in an sqlite database. Sometime during the implementation of this feature for Firefox 2, someone started refering to it to by that name, possibly because that is what the class name of its implementation is. Unfortunately, the naming of the class was a bit of an accident caused because the underlying DOM implementation doesn't like classes that don't begin with 'nsDOM' and I didn't have time to figure out why. Anyway, internally we can still call it DOM Storage if needed, as I don't have another suitable short enough name, but to users it should always be referred to as 'Client-side session and persistent storage' or any other name deemed acceptable by the WHAT-WG.