Firing restore events can trigger code that changes the URI in the docshell or triggers history traversals. That would synchronously reenter nsDocShell::RestorePresentation and probably make the docshell somewhat confused.

I think this could apply to the following events that can be fired during restore: pageshow resize DOMLinkAdded

Do we still have a sync reentry here now that we're doing at least part of RestorePresentation async?

I think it might still be possible to do this, but via the PageHide event.

I think this confuses us. If I do the following: 1. Start firefox, go to google.com 2. Load the attached testcase 3. Type mozilla.org into the urlbar and hit enter I get a whole slew of bad assertions on the console, and the result is that google.com appears, and the throbber spins continuously. Here is the console log: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file /builds/mozilla/bfcache/mozilla/dom/src/base/nsGlobalWindow.cpp, line 6119 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file /builds/mozilla/bfcache/mozilla/docshell/base/nsDocShell.cpp, line 5291 ###!!! ASSERTION: Overwriting an existing document channel!: '(loadFlags & nsIChannel::LOAD_REPLACE) || !(mDocumentRequest.get())', file /builds/mozilla/bfcache/mozilla/uriloader/base/nsDocLoader.cpp, line 497 Break: at file /builds/mozilla/bfcache/mozilla/uriloader/base/nsDocLoader.cpp, line 497 ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "'Permission denied to set property Window.sf' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "<unknown>" data: no] ************************************************************ ###!!! ASSERTION: subshell not in the map: 'shellContent', file /builds/mozilla/bfcache/mozilla/docshell/base/nsDocShell.cpp, line 3623 Break: at file /builds/mozilla/bfcache/mozilla/docshell/base/nsDocShell.cpp, line 3623 WARNING: NS_ENSURE_TRUE(aContent) failed, file /builds/mozilla/bfcache/mozilla/layout/base/nsFrameManager.cpp, line 338 ###!!! ASSERTION: file descriptor not closed: '!mFD', file /builds/mozilla/bfcache/mozilla/netwerk/cache/src/nsDiskCacheStreams.cpp, line 346 Break: at file /builds/mozilla/bfcache/mozilla/netwerk/cache/src/nsDiskCacheStreams.cpp, line 346

This is a tough call, but I think this is unlikely to happen on real web sites... unless the testcase can be shown to be some kind of security exploit, I don't think this is high enough priority to make the 1.5 cut at this stage.