Closed Bug 292945 Opened 19 years ago Closed 19 years ago

bfcache/fastback code can synchronously trigger off a timeout


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

Not set





(Reporter: bzbarsky, Assigned: bryner)



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.
Target Milestone: --- → mozilla1.8beta4
Flags: blocking1.8b4+

Looks bfcache related - so putting it on your list.  Let us know if it should
move elsewhere.
Assignee: general → bryner
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).
Closed: 19 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.