We have decided to make a number of architectural changes to the Storage Panel to simplify the process of migrating to fission. Most of the original code can be reused but a number of changes need to be made in order to prepare the code for migration.
We will first make a number of changes to the Storage Panel and then migrate it to the application panel (and to fission).
These changes can be summarised as follows:
- Replace the observer approach with a simple refresh button.
- Change the indexedDB actor to use
indexedDB.databases()
instead of direct file access. - Stop using class inheritance and move the actors out into their own files.
- Create a simple skeleton storage inspector inside the application panel
- Migrate each panel to the application panel.
- Make use of TargetList for fission compatibility.
-
Persist visited origins: When debugging storage between redirecting pages and iframes, I want an option to persist all known origins, so that I can see which storage was created or accessed even though the pages are gone. We currently drop pages that no longer exist.
-
Refresh button along with option to refresh every X seconds.
-
Add or edit cookie, localStorage and sessionStorage: At the moment we just do this in the table but using a form in the sidebar to add, view and edit an item would allow better presentation of data and allow us to use date pickers etc. We can only do this for cookies, localStorage and sessionStorage because we know which data types to expect.
-
Double-keyed storage: Double-keyed storage refers to first party isolation of storage items. In a nutshell this means that such storage is actually keyed by the URL of the browser window then the iframe URL and then the storage item name.
If site1.com and site2.com both had iframes containing site3.com and site3 had a cookie named "myCookie" we would have 2 independant cookies:
- site1.com -> site3.com -> myCookie
- site2.com -> site3.com -> myCookie
Showing this in the tree makes sense but with a lot of iframes it could get very messy.
-
Storage Dashboard: When storing complex data, I want to see where data is kept and how much, so that I can monitor my quota and inspect the biggest buckets. I would expect to see the following if a storage item is selected but not a domain e.g. cookies:
- The space taken by the current cookies on the page.
- The available to the current cookies on the page.
- The total space used by cookies in the whole browser.
- The total space available to cookies in the whole browser.
-
Should we combine sessionStorage, localStorage into 1 table?
-
Create a simple skeleton storage inspector inside the application panel
- This should be a split view containing the storage tree structure and a simple message for each storage type.
- Bug 1594810 - Remove DevTools support for IndexedDB "persistent" storage r=jdescottes
- Change the indexedDB actor to use
indexedDB.databases()
instead of direct file access.
-
Bug 1578975 - [meta] Make the Storage Inspector compatible with Fission and migrate it into the Application Panel.
- Blocks Bug 1451850
-
[Cache Storage] Remove observers from storage.js (use refresh button)
-
[Cookie Actor] Remove observers from storage.js (use refresh button)
-
[Local Storage Actor] Remove observers from storage.js (use refresh button)
-
[Session Storage Actor] Remove observers from storage.js (use refresh button)
-
[Web Extension Storage Actor] Remove observers from storage.js (use refresh button)
-
[Cache Storage actor] Stop using class inheritance and move the actor out into it's own file.
-
[Cookie actor] Stop using class inheritance and move the actor out into it's own file.
-
[IndexedDB actor] Stop using class inheritance and move the actor out into it's own file.
-
[Local Storage actor] Stop using class inheritance and move the actor out into it's own file.
-
[Session Storage actor] Stop using class inheritance and move the actor out into it's own file.
-
[Web Extension Storage actor] Stop using class inheritance and move the actor out into it's own file.
-
[Cache Storage] Migrate the panel to the application panel.
-
[Cookie Actor] Migrate the panel to the application panel.
-
[Local Storage Actor] Migrate the panel to the application panel.
-
[Session Storage Actor] Migrate the panel to the application panel.
-
[Web Extension Storage Actor] Migrate the panel to the application panel.
-
[Cache Storage] Make use of TargetList for fission compatibility
Bug Notes
-
[Cookie Actor] Make use of TargetList for fission compatibility
Bug Notes
-
[Local Storage Actor] Make use of TargetList for fission compatibility
Bug Notes
-
[Session Storage Actor] Make use of TargetList for fission compatibility
Bug Notes
-
[Web Extension Storage Actor] Make use of TargetList for fission compatibility
Bug Notes
- https://docs.google.com/document/d/1RJJsx4eT_NmWqtIOJbm6IPejFsTt6RWz7ldqAVwo4l8/edit#
- https://phabricator.services.mozilla.com/D54022 - Search for protohighlighter
- https://docs.google.com/document/d/12N08gQsOeHGUz_aZRX3DcuW84zD29M7B2DSZsymhY8Q/edit#heading=h.15vj0jcl6uv - Context Switching (future)
- Run talos tests with
--enable-fission
Bug xxxxxxx - Disable storage inspector tests when fission enabled.
Normally all tests failing with fission are already disabled: see "fail-if = fission" in https://searchfox.org/mozilla-central/source/devtools/client/storage/test/browser.ini . Do we really need to skip additional tests?