bfcache/fastback code can synchronously trigger off a timeout

RESOLVED FIXED in mozilla1.8beta4



14 years ago
13 years ago


(Reporter: bzbarsky, Assigned: bryner)


Bug Flags:
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)


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

14 years ago
While attempting to write a testcase for this, I discovered bug 301516.
Target Milestone: --- → mozilla1.8beta4
Flags: blocking1.8b4+

Comment 2

14 years ago

Looks bfcache related - so putting it on your list.  Let us know if it should
move elsewhere.
Assignee: general → bryner

Comment 3

14 years ago
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).
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.