292945 - bfcache/fastback code can synchronously trigger off a timeout

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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

Comment 1

[Brian Ryner (not reading)]

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

Comment 2

[Mike Schroepfer]

Bryner,

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

Comment 3

[Brian Ryner (not reading)]

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).