Convert from SQLite to IndexedDB

Add-ons Development
#1

I use SQLite in my overlay add-on and will need to switch to IndexedDB when I port to Webextensions.

Have anyone else done this who will share the steps needed.
Do anyone know of any good documentation on how to make this switch.

Thanks.

#2

I don’t have any personal experience, but this came up before. I’ll just quote myself:

I don’t know if that is fixed.

Nope, it isn’t.

#3

Thanks for presenting an alternative.

But if possible I will stick as much to standards as possible.

Do one any have a link to bug with indexedDB, so I can track the progress?

#4

I have never filed a bug and haven’t searched for one either.

I have only encountered this bug with an extension I haven’t in my own personal profile, which i quite old by now - and packed with all kinds of privacy related add-ons and preferences.

To file a bug I would need to find out what is actually causing it, which would definitely take quite some time. The last time I did that it still took month for the bug to be fixed (and I think that was more or less by accident too). So given my usecase, it seemed much quicker to implement a workaround.

#5

Can anyone involved in the development of WebExtensions provide some info on this.

If indexedDB is the new standard and it is buggy, then that seems like a pretty important thing to fix.

It is not really encouraging to know that indexedDB is buggy before deciding to convert from SQLite.

Can anyone let me know if it is ‘safe’?

#6

I’m not exactly sure what this refers to, but I did just confirm that if you disable indexeddb using the about:config preference “dom.indexeddb.enabled”, then WebExtensions can’t use it. Is that the issue you mean?

There is some interesting history here, where this preference was made content-only, in part so as not to break bootstrapped extensions.

I just asked in the #webextensions IRC channel, and the consensus from the dev team was that they’d agree to do the same for WebExtensions, so I filed a bug. I don’t think it would be a very high priority bug though (I guess because very few users would disable IndexedDB).

Will

1 Like
#7

I had already “dom.indexeddb.enabled” set to true (default) and my extension is definitely unable to use the indexedDB. So something else is causing it. I will try to find out what it is, but as I said, this is the kind of bug that takes time to track down.

for WebExtensions, so I filed a bug

Certainly can’t harm anyway.

#8

Turns out that deleting storage/default/* in the profile folder solved the problem; restoring the folders from a backup also restores the problem.

This is a tree /f over the old storage/default/

├───moz-extension+++9446f127-0320-4a4d-913e-3e1e1738ac97
│   │   .metadata
│   │
│   └───idb
│       │   1907939001voifdneIo.sqlite
│       │
│       └───1907939001voifdneIo.files
├───moz-extension+++c88ba4ee-c57e-4b9d-8c95-16469cf01c9d
│   │   .metadata
│   │
│   └───idb
│       │   1907939001voifdneIo.sqlite
│       │
│       └───1907939001voifdneIo.files
└───moz-extension+++c93a0418-ac32-4dbb-af56-89640f5380b8
    │   .metadata
    │
    └───idb
        │   1907939001voifdneIo.sqlite
        │
        └───1907939001voifdneIo.files

All files in these folders are at least half a year old.

And this is the new one after loading my extension (which has saved one Blob in a DB called videoInfo) and visiting youtube.com (which it works with)

├───https+++www.youtube.com
│   │   .metadata
│   │   .metadata-v2
│   │
│   └───cache
│       │   caches.sqlite
│       │
│       └───morgue
│           └───36
│                   {13d62603-9b4c-4aa9-b65f-833117df8c24}.final
│
└───moz-extension+++bda124a5-abaf-4806-b364-b49c706780dc^addonId=%40youtubeoverhaul
    │   .metadata
    │   .metadata-v2
    │
    └───idb
        │   1907939001voifdneIo.sqlite
        │
        └───1907939001voifdneIo.files
            │   1
            │
            └───journals

I don’t see a correlation between the tow trees, but deleting the old files seems to unclog something. Deleting the new files and putting the old ones back reverts that.

I guess this can be categorized as “weird, but probably won’t happen again”.

2 Likes