Refactor chromeStorageDB

[eight04]

Fixes #839

• Fix: a save style error. The process failed but the data is stored in the DB.
• Fix: a race condition that may result in duplicated ID.

To test this branch, you have to switch to chrome storage DB by setting localStorage.dbInChromeStorage to "true" and reload the extension.

[narcolepticinsomniac]

To test this branch, you have to switch to chrome storage DB by setting localStorage.dbInChromeStorage to "true" and reload the extension.

Or you can test in FF by setting it to "never remember history". AFAIK, the fallback storage should never be triggered in Chromium, correct? Isn't that one of the main bugs this PR is addressing? There's a couple/few settings/configs in FF which interfere with webextensions' access to indexedDB, so it it switches to the slower, accessible storage.

This PR seems to work as originally intended, minus the bug where the fallback is erroneously triggered, presumably. As I understand it, the major drawback with the fallback has always been that by the time it's triggered, it's too late to transfer existing styles from indexedDB. Would it be worthwhile to always mirror them?

If not, then I guess I guess this improves the status quo, so we can merge as-is.

[eight04]

the fallback storage should never be triggered in Chromium, correct?

No. The fallback is triggered when indexedDB is unavailable. #839 also uses Chrome.

This PR seems to work as originally intended, minus the bug where the fallback is erroneously triggered,

No. This PR doesn't change how the fallback is triggered. It fixes:

1. A TypeError in chromeStorageDB when saving/installing a style.
2. A race condition that may result in duplicated style ID.
3. Drop chromeLocal, which doesn't handle errors correctly.

Would it be worthwhile to always mirror them?

There are some discussions here: #539

[narcolepticinsomniac]

No. The fallback is triggered when indexedDB is unavailable

I realize that, I just assumed the fallback was strictly a FF workaround, and indexedDB should always be available in Chromium.

#839 also uses Chrome.

I figured the fallback was getting triggered in Chromium due to a bug, which I thought you were addressing here. Are there really scenarios where indexedDB would legitimately be unavailable in Chromium?

[narcolepticinsomniac]

I get that this PR fixes issues with the fallback storage, and that's great. I'm still confused about #839 though, given the fact that I always assumed the fallback should never be triggered in Chromium.

Obviously it was triggered in Chromium, and you made it pretty clear that "this PR doesn't change how the fallback is triggered". Unless I'm way off, and there is some legitimate reason the fallback would be triggered in Chromium, that still leaves us with a significant bug.

[tophf]

fallback should never be triggered in Chromium

FWIW it did in #182, #187.

[narcolepticinsomniac]

So... it shouldn't happen, but sometimes it does, and it's nothing new. Guess that answers the question. At least this PR improves the fallback then.