Closed Bug 829904 Opened 11 years ago Closed 11 years ago

Collect Session Restore data in the background

Categories

(Firefox :: Session Restore, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 838577

People

(Reporter: Yoric, Unassigned)

References

Details

(Whiteboard: [Snappy][sync:tabs])

At the moment, collection Session restore data is done in a blocking manner:
getBrowserState, getWindowState, getTabState freeze the main thread while they collect their data, causing jank.

We could avoid that jank by reorganizing data collection as follows:
- the Session restore service maintains a cache of the state, which may not be full up to date;
- getBrowserState, getWindowState, getTabState return (subsets of) the latest cached state;
- a new method |snapshot| triggers an asynchronous update to the cache (or a subset thereof), returning a promise and/or accepting a custom observer;
- saveStateDelayed is altered to proceed only once the snapshot is complete.
gps: I believe that you are the sole user of getBrowserState on m-c, will this break anything in Sync?
Flags: needinfo?(gps)
Deferring to rnewman since he has more of Sync paged into his brain than I do right now.
Flags: needinfo?(gps) → needinfo?(rnewman)
The only two things we do with the session instance is:

* getBrowserState to find out open tabs
* setTabValue in an observer notification to set a weaveLastUsed timestamp.

The latter doesn't apply here, I suppose.

I would be very happy to consume an alternative API which provides the set of windows and open tabs. Having a *slightly* stale set through the current API would be fine.
Flags: needinfo?(rnewman)
Blocks: 608617
Whiteboard: [Snappy] → [Snappy][sync:tabs]
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.