Storage Panel Architecture¶
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.
Content process: LocalStorage, SessionStorage, Cache.
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