Support inspection of WebExtension storage APIs data from the Storage panel of the WebExtension Addon Debugger toolbox

NEW
Unassigned

Status

()

Toolkit
WebExtensions: Storage
P3
normal
2 years ago
22 days ago

People

(Reporter: Nika, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: devtools, triaged)

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
It would be nice to be able to use the storage tab to inspect the data which is stored by the web extension within the storage.StorageArea API.

Comment 1

2 years ago
can you update the summary so it's clearer (based on your work) for when we get to this work?
Flags: needinfo?(lgreco)
Priority: -- → P3
Whiteboard: devtools, triaged

Comment 2

2 years ago
The goal of this issue is to create the needed Storage actors[1] to be able to inspect and manipulate data stored by an addon in the WebExtension storage APIs and to ensure that the new storage actors are activated only when the debugging target is a WebExtension, and finally that the new actors are correctly recognized and used in the Storage panel client.

[1]: the Storage actors implementation seems to provide a base abstraction that is then extended by the specialized storage actors (e.g. cookies, local and session storages etc., as an example of specialized storage actor, a link to the "cookies" storage actor implementation: http://searchfox.org/mozilla-central/source/devtools/server/actors/storage.js#375)
Flags: needinfo?(lgreco)
Summary: Allow using the storage tab for inspecting data stored using the storage.StorageArea API → Support inspection of WebExtension storage APIs data from the Storage panel of the WebExtension Addon Debugger toolbox

Comment 3

7 months ago
Just adding my 2¢, I spent about an hour today trying to figure out why this code wasn't working:

chrome.storage.local.set({'asdf': 'asdf'});

Seemed like it ran fine with no exceptions, but when I looked at the area of the debugger that was labelled "Local Storage", and which then showed, "moz-extension://{my-id}" as a sub-entry, I couldn't get my key to show up. Little did I know that we've got two kinds of key-value storage called local storage. Ugh!

Anyway, all of this pain would have been avoided if we showed chrome.storage in the debugger as an additional item.

Thanks.

Comment 4

7 months ago
Created attachment 8924286 [details]
The *very* confusing section of the debugger

This image shows the part of the debugger I stared at today while trying in vain to set a value...alas, I would have been there forever.

Comment 5

7 months ago
Hi mlissner,

That section of the DevTools Storage panel in attachment 8924286 [details] is related to the localStorage web API:

- https://developer.mozilla.org/en-US/docs/Web/API/Storage/LocalStorage

This is an API that any webpage can use and that is also available to the extension pages 
(but it is not available from the content scripts, because from a content script the window object is related to the webpage and not the extension page, and so window.localStorage is the localStorage of the webpage from a content script).

The DevTools Storage panel already support the localStorage web API, but it doesn't yet support the browser.storage.local (or chrome.storage.local) yet, and so the goal of this issue is to add a new section for these extension storage in the DevTools Storage panel (not to remove or re-purpose the section related to the localStorage web API).

I do agree that it is very unfortunate (and pretty confusing) that the two APIs have very similar names (storage.local vs. localStorage).

Comment 6

7 months ago
Yep, I understand, thanks Luca. I was just trying to chime in with an example of the kinds of confusion that are caused by not having a panel for chrome.storage.local. It'd be great to get this panel in place.

Updated

6 months ago
Component: WebExtensions: Developer Tools → WebExtensions: Storage
You need to log in before you can comment on or make changes to this bug.