Open Bug 833790 Opened 13 years ago Updated 3 years ago

[Session Manager] Best Effort Session Restore

Categories

(Firefox :: Session Restore, defect)

x86
macOS
defect

Tracking

()

People

(Reporter: Yoric, Unassigned)

References

(Blocks 1 open bug)

Details

Once we have the basic of the new SessionManager, we should use it to reimplement a new version of the current SessionRestore API. Given that the Session Manager API is designed to be asynchronous, this SessionRestore API will provide "latest consistent snapshot", rather than the current version that blocks the main thread to always obtain an absolutely current version of the data.
David, how actionable is this bug with sessionstore in its current state?
Flags: needinfo?(dteller)
(In reply to Mike de Boer [:mikedeboer] from comment #1) > David, how actionable is this bug with sessionstore in its current state? Ouch, that's a discussion dating back from 2013. I don't remember the full context, as you can imagine. The general idea, at the time, was to implement a fully async version of Session Restore and progressively expose it to the world. Unfortunately, I don't think that much progress was done in this direction. However, with the advent of WebExtension, now might be a good time to think about it again. I believe that, at this stage, the best thing to do would be: - get in touch with the WebExtension team; - find out if they plan to offer an API to access the current state of the session; - if so, design together a sane API for Session Restore, which would be, among other things, async, not based on strings, etc; - come up with a SessionRestoreAPI.jsm implementing this API, initially on top of the current ugly API; - ensure that WebExtension uses this new API, rather than the old one; - progressively migrate all clients of Session Restore to SessionRestoreAPI.jsm; - progressively migrate the implementation of SessionRestoreAPI to something "natively sane". Does this make sense to you?
Flags: needinfo?(dteller) → needinfo?(mdeboer)
Well, this API has already been implemented, with my help, in bug 1300399. It's been bolted on SessionStore.jsm, where we added a few niceties to make it possible to match Chrome's API. See http://searchfox.org/mozilla-central/source/browser/components/extensions/ext-sessions.js for its implementation (it's quite a small file, since most of the heavy lifting is done by SessionStore.jsm). Once the only extensions possible are WebExtensions in Firefox (planned end-of-year), the 'old' API will be effectively deprecated. This also means that we can make changes under the hood to make the data we provide to the WebExtension API to be an always up-to-date snapshot. I have to say, however, that the current state retrieval doesn't seem terribly expensive due to caching, other than we iterate over all windows each time in the WebExtension API code - also not terribly expensive.
Flags: needinfo?(mdeboer)
> Well, this API has already been implemented, with my help, in bug 1300399. [...] > Once the only extensions possible are WebExtensions in Firefox (planned end-of-year), the 'old' API will be effectively deprecated. Oh, that's good! > I have to say, however, that the current state retrieval doesn't seem terribly expensive due to caching, other than we iterate over all windows each time in the WebExtension API code - also not terribly expensive. A long time ago, I remember that we spent looots of time (de)serializing JSON, plus the time spent collecting, which involved lots of walking through frames looking for cookies. With faster computers/JIT/DOM things may have changed.
All I can say is that that the new ext-sessions.js uses SessionStore.getClosedWindowData(aAsString = false) - thus without JSON.stringify all the things, but a structured clone instead - and SessionStore.getClosedTabData(window, aAsString = false) - thus without JSON.stringify all the things, but a structured clone instead - which extract data from SessionStore._closedWindows and SessionStore._windows[aWindow.__SSi]._closedTabs or from the DyingWindowCache respectively. So no frame walking or cookie fetching is used in the new WebExtensions API.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.