Skip to content

Latest commit

 

History

History

dom_storage

README.md

DOM Storage

Under Contruction

Session Storage (Mojo)

Under Contruction

The browser manages the lifetime of session storage namespaces with SessionStorageNamespaceImpl.

The object calls SessionStorageContextMojo::CreateSessionNamespace when it is created, and SessionStorageContextMojo::DeleteSessionNamespace when it's destructed.

This object is primarily held by both the NavigationControllerImpl and in the ContentPlatformSpecificTabData which is used to restore tabs. The services stores recent tab closures for possible browser restore here.

In the future when it's fully mojo-ified, the lifetime will be managed by the mojo SessionStorageNamespace which can be passed to the renderer and the session restore service. There will always need to be an ID though as we save this ID to disk in the session restore service.

High Level Access And Lifetime Flow

  1. Before a renderer tab is opened, a SessionStorageNamespaceImpl object is created, which in turn calls SessionStorageContextMojo::CreateSessionNamespace.
    • This can happen by either navigation or session restore.
  2. The following can happen in any order:
    • Renderer creation, usage, and destruction
      • The session_namespace_id is sent to the renderer, which uses StorageParitionService to access storage.
      • The renderer is destroyed, calling SessionStorageContextMojo::DeleteSessionNamespace.
        • If SetShouldPersist(true) was not called (or called with false), then the data is deleted from disk.
    • SetShouldPersist(true) is called from the session restores service, which means the data should NOT be deleted on disk when the namespace is destroyed. This is called for all tabs that the session restore services wants to persist to disk.
    • The session restore service calls DomStorageContext::StartScavengingUnusedSessionStorage to clean up any namespaces that are on disk but were not used by any recreated tab. This is an 'after startup task', and usually happens before SetShouldPesist is called.

Possible Edge Case: Persisted Data vs Stale Disk Data

Namespace is created, persisted, destroyed, and then we scavange unused session storage.

Flow:

  1. SessionStorageContextMojo::CreateSessionNamespace
  2. SetShouldPersist(true)
  3. SessionStorageContextMojo::DeleteSessionNamespace
  4. DomStorageContext::StartScavengingUnusedSessionStorage
  5. The data should still reside on disk after scavenging.

The namespace could accidentally be considered a 'leftover' namespace by the scavenging algorithm and deleted from disk.

Navigation Details

When navigating from a previous frame, the previous frame will allocate a new session storage id for the new frame, as well as issue the 'clone' call here.

The session_namespace_id for a frame's session storage is stored in the CreateNewWindowParams object in frame.mojom.

If the frame wasn't created from a previous frame, the SessionStorage namespace object is created here and the id is accessed here.

Renderer Connection to Session Storage

Renderers use the session_namespace_id from the CreateNewWindowParams. They access session storage by using StoragePartitionService::OpenSessionStorage, and then SessionStorageNamespace::OpenArea with the session_namespace_id.

They can then bind to a LevelDBWrapper on a per-origin basis.

Session Restore Service Interaction

A reference to the session is stored in the ContentPlatformSpecificTabData which is used to restore recently closed tabs. The services stores recent tab closures for possible browser restore here.

When tabs are inserted, the session storage service saves the id to disk here using the commands (which are saved to disk). The session id is also accessed here for saving in commands in TabClosing and BuildCommandsForTab.