See bug 274784 comment 14, where jst says: ------------------------------------------------- Oh, and on an unrelated note, I wonder if the state-saving code could be triggerd from a timeout? If it could, then there's some nasty timer issues to deal with. When an XPCOM timer fires, we may run more than one JS timeout if the XPCOM timer fires late (which is not that uncommon), or if there are more than one timeout with the same deadline. In such a case, we need to stop firing timeouts if we end up saving state, and we need to make sure we never save timeouts that are on the stack (if this code is triggerd from a timeout there will be a timeout in the timeout list that's not heap allocated, look for dummy_timeout in nsGlobalWindow::RunTimeout()). Separate bug, I guess, but it needs fixing, I think (or are location changes from JS *guaranteed* to be async?). ------------------------------------------------- While I think normal non-history loads are guaranteed to be async, JS can call history.back()/history.forward(), which are very much sync when bfcache/fastback is enabled

While attempting to write a testcase for this, I discovered bug 301516.

Bryner, Looks bfcache related - so putting it on your list. Let us know if it should move elsewhere.

I think this is no longer an issue. The state-saving code now only runs from the PLEvent callback in Docshell (or from SetupNewViewer, which would also be running on top of a PLEvent).