Local Storage Debugger Workaround

Add-ons Development
1

New here; not long released My First Add-On to AMO.

Had been tearing my hair out trying to figure out why browser.local.storage was manifestly working fine but the debugger wasn’t showing anything in the Storage tab, and eventually found this useful and explanatory bugzilla entry:

Turns out the debugger shows data from the localStorage web API, not the browser.local.storage webextension API. An important distinction, though when the browser knows you have clicked on ‘Debug My Webextension’ there is an argument that such behaviour could perhaps be modified for the better and is at least certainly confusing.

FWIW, I found a workaround, involving typing the following line into the debugger console (NB - not the regular console, where this doesn’t work as it doesn’t know what ‘browser’ is):

browser.storage.local.get(null, function(items) { console.log(items); });

Two questions: a) is there a better way (new here see above), and b) what is the likelihood of getting a fix for this into the Storage tab of the debugger itself?

2

I use a similar technique currently (just that I use promises instead…)

I wonder if the move to indexedDB as the storage backend for storage.local will make it accessible in the storage debugger, albeit hidden. I haven’t been able to locate it so far on nightly.

3

I’d hope that with the indexedDB backend, Firefox would also use a more efficient serialization format, like BSON/WebPack/… .
Which would mean that even if you did get to read the database, that would be rather useless.

But how about the console supporting
await browser.storage.local.get(null)
Wouldn’t that be something …

4

That would indeed be something: GitHub - tc39/proposal-top-level-await: top-level `await` proposal for ECMAScript (stage 4)

5

That’s indeed interesting, but actually taking it much further than I wanted to hint at.

Besides the lack of the Promise-bases browser namespace (let’s assume its polyfilled), the above would work as expected in Chromes console.

From what I can infer, they do something like this with the code entered in the console:

  1. compile as normal function
    • if it throws, save the error
    • else run and exit
  2. compile as async function
    • if it throws, throw the saved error
    • else run, await and exit
6

I can highly recommend to use webextension-polyfill in Chrome to enable Promise based API. Especially once you start using async / await.

Regarding easy printing of result with console.log, you can just pass the whole function to then or any callback like this:

browser.storage.local.get().then(console.log)

which is similar to Chrome version with await:

await browser.storage.local.get()

You can already vote for this feature in Firefox here:

7

Ah. It would be really nice to get that in Firefox as well.

My code uses await all over the place. The console not supporting that severely restricts it’s usefulness when evaluating code snippets there.

And I didn’t know that one could finally use the functions on the console without explicitly binding the this context before. I thought that only worked in node.js.