Storage Panel Architecture

Actor structure

Legacy

This is currently only used by the browser toolbox and when inspecting Web Extensions.

• We have an actor per storage type.

• These actors are contained in a pool managed by a global Storage actor. See source code of the actor and source code of the pool

• Each specific storage type actor has a reference back to this global Storage actor.

Resource-based

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

• 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[^web-extension-not-implemented].

  • Content process: LocalStorage, SessionStorage, Cache.

[^web-extension-not-implemented]: Web Extension has not yet been implemented in this new architecture.

Flow

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

• 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

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".

Navigation

Fission ON, target switching OFF

• Deletion of content process storage hosts is handled within the onTargetDestroyed callback.

• Deletion of parent process storage hosts is handled with "single-store-update" events, fired when the StorageMock detects a "window-global-destroyed" event.

• When the new target is available, new storage actors are spawned from their watchers’ watch method and are sent as resources in the onAvailable callback.

Fission ON, target switching ON

Similar to the previous scenario (fission on, target switching off), but parent process storage resources are handled differently, since their watchers remain instantiated.

• New actors for parent process resources are not spawned by their watchers watch, but as a callback of "window-global-created".

• Some times there’s a race condition between a target being available and firing "window-global-created". There is a delay to send the resource to the client, to ensure that any onTargetAvailable callback is processed first.

  • The new actor/resource is sent after a "target-available-form" event.

CRUD operations

Add a new cookie

Other CRUD operations work very similar to this one.

• We call StorageMock.getWindowFromHost so we can get the storage principal. Since this is a parent process resource, it doesn’t have access to an actual window, so it returns a mock instead (but with a real principal).

• To detect changes in storage, we subscribe to different events that platform provides via Services.obs.addObserver.

• To manipulate storage data, we use different methods depending on the storage type. For cookies, we use the API provided by Services.cookies.