Storage Panel Architecture¶
This is currently only used by the browser toolbox and when inspecting Web Extensions.
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
The specific actors for each storage type are spawned by watchers instead.
The reference to a global
Storageactor 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.
Some considerations to keep in mind:
In the Storage Panel, resources are fronts.
These fronts contain a
hostsobject, which is populated with the host name, and the actual storage data it contains.
In the client, we get as part of the
Content process storage types: multiple resources, one per target
Parent process storage types: a single resource
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).
We get all the storage fronts as new resources sent in the
After a remote target has been added, we get new additions as
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
onAvailablecallback, instead of
Parent process storage resources keep using the
"single-store-update"method. This is possible due to their
StorageMockactors emitting a fake
"window-ready"event after a