Storage Panel Architecture

Actor structure

This is the new architecture that is being implemented to support Fission. It’s currently used when inspecting tabs.

Class structure architecture (resource-based)

  • We no longer have a global Storage actor.

  • The specific actors for each storage type are spawned by watchers instead.

  • The reference to a global Storage actor that each actor has now points to a mock instead.

  • Some watchers require to be run in the parent process, while others can be run in the content process.

    • Parent process: Cookies, IndexedDB, Web Extension.

    • Content process: LocalStorage, SessionStorage, Cache.


Some considerations to keep in mind:

  • In the Storage Panel, resources are fronts.

  • These fronts contain a hosts object, which is populated with the host name, and the actual storage data it contains.

  • In the client, we get as part of the onAvailable callback of ResourceCommand.watchResources:

    • Content process storage types: multiple resources, one per target

    • Parent process storage types: a single resource

Initial load

Web page loaded, open toolbox. Later on, we see what happens if a new remote target is added (for instance, an iframe is created that points to a different host).

Fission OFF

Initial load diagram, fission off

  • We get all the storage fronts as new resources sent in the onAvailable callback for watchResources.

  • After a remote target has been added, we get new additions as "single-store-update" events.

Fission ON

Initial load diagram, fission on

Similar to the previous scenario (fission off), but now when a new remote target is added:

  • We get content process storage resources in a new onAvailable callback, instead of "single-store-update".

  • Parent process storage resources keep using the "single-store-update" method. This is possible due to their StorageMock actors emitting a fake "window-ready" event after a "window-global-created".

CRUD operations