Help detecting IndexDB errors automatically

[mikelei8291]

The add-on has been showing me IndexDB errors for a long time. However, there are thousands of DBs from all the site that I've visited before. I also tried the method in the wiki several times, it worked once but then got broken again. Is there any way to detect which DB file is corrupted automatically? It's not really practical to copy them one by one and restart the browser every time.

[perXautomatik]

i like syncing and merging sessions between my computers, so corruptions happens every now and then. i simply uninstall the plugin and reinstall it and everything is fine (after downloading from drive).

solution: would be great to have something like "discard db and rebuild" or something so one wouldn't need to go through the process of reinstalling the whole plugin.

[mikelei8291]

i simply uninstall the plugin and reinstall it and everything is fine (after downloading from drive).

Reinstalling doesn't solve my problem. Is it that the corrupted file was created by other add-ons or websites? However, all other add-ons and websites worked fine.

I'd better list my environment here:

• Firefox Developer Edition 81.0b9
• Windows 10 1709

[perXautomatik]

Is it that the corrupted file was created by other add-ons or websites?

Might be in my case, I thought that it was related to heavy read-write cycles (large sessions written to etc, might be other scripts interfering with a single write, making it take to long, and therefore corrupting the file, possibly)

Worth adding that I'm running it in Opera Gx, based on chrome as I understand it, so I assume it's different from a Mozilla environment.

[perXautomatik]

It seems like my "problem" is solved (don't need to invalidate my stuff and reinstall the plugging), the sessions shows corrupted at first, then after reloading the page or similar, the session is up and running again, thank you dev!

[mikelei8291]

after reloading the page or similar, the session is up and running again

@perXautomatik What do you mean by reloading the page? What page?

[mikelei8291]

The problem seemed to be solved after re-installing the extension and not reloading it after installation. I used to switch on the "Allow extension to run in private browsing mode" option right after installation, and this will cause the extension to reload, then run into this issue. However, this will make the extension not usable at all in any private session, although maybe usable in normal browsing mode.

The behaviour can be reproduced in my Firefox Dev Edition 82.0b7. Simply install, disable and then enable the extension.

Also, I don't know if the extension will run into this issue again after a browser restart, as this can also be a kind of "reload". Another problem is that this "reload" can happen in many cases, such as an extension update.

@sienori Do you have any insights on this issue?

[mikelei8291]

Update: after updating and restarting Firefox, the extension still works fine. It's also very interesting that disable and then enable the extension on Chrome also causes this issue. Is it really because of some corrupted IndexedDB or something else?

[perXautomatik]

after reloading the page or similar, the session is up and running again

@perXautomatik What do you mean by reloading the page? What page?

to clarify; i had selected 'Open session list in tab' so therefore i could refresh the page with the regular browser control

i can confirm the 'disable and then enable the extension on Chrome also causes this issue' as it does for opera gx as well

[mikhoul]

@sienori Would it be possible that the extension check itself for DB index corruption once every 3-4 hours or even better with a "listener" and if the DB is corrupted it would restart/reset automatically the extension.

It would not address the issue as why the DB corrupt but at least for the users it would fix 99% of the inconveniences.

Regards :octocat:

[mikelei8291]

@mikhoul As far as I know, there is no such a "listener" for indexDB corruptions that is implemented natively, and cannot be implemented by ourselves without using polling, which may affect the performance of the machine. Also, all the saved sessions will be lost after the indexDB reset, unless restored from sync afterwards, so this will not fix any inconvenience at all, but create more problems.

[mikhoul]

Also, all the saved sessions will be lost after the indexDB reset,

Bot resetting the IndexDB but the installation of the extension, when you reinstall the extension manually the indexDB error goes away and all your session are back.

I'm pretty sure there is a way to monitor the state of indexDB since on the session page there is a message about the indexDB error... in some way the extension is already aware the indexDB is corrupted.

[mikelei8291]

@mikhoul Can you revise the first sentence of your comment? I'm very confused.

It seems that you are also confused by the term "monitor" and "detect", where the first term describes a consecutive "awareness" of the state of the indeDB, while the second term describes a single shot action of finding out whether the indexDB is corrupted.

The fact is that there is indeed a way to monitor the state of indexDB, and I have already pointed it out in my previous comment - by polling, which may have performance issues. However, this is not what the extension has been using, the extension knows that the indexDB is corrupted because the access to the indexDB fails and it catches that error, not because of "some way" that you imagined and was "pretty sure" of. Can you please at least investigate into this issue first before posting your comment?

[sienori]

IndexedDB error occurs if the storage in Firefox is corrupted. It cannot be repaired automatically. This is because the extension's API does not allow access to files in the storage area.

Also, After disabling and re-enabling the extension, an IndexedDB error seems to be displayed. In this case, restarting the browser solves the problem. The IndexedDB Error page prompts the user to restart the browser, so the user should be able to solve the problem.

[mikelei8291]

@sienori Do you have any idea about why disable and re-enable the extension will display this error in the first place?

[sienori]

@mikelei8291 The initialization process did not work when the extension was disabled and re-enabled. I fixed it! https://github.com/sienori/Tab-Session-Manager/commit/a73981594b2bb742d8a11b0a070b292ff290fbad

[mikhoul]

@sienori

IndexedDB error occurs if the storage in Firefox is corrupted. It cannot be repaired automatically. This is because the extension's API does not allow access to files in the storage area.

Also, After disabling and re-enabling the extension, an IndexedDB error seems to be displayed. In this case, restarting the browser solves the problem. The IndexedDB Error page prompts the user to restart the browser, so the user should be able to solve the problem.

I use Chromium (Brave),

Sometime I see this error:

First: I use a packed version of the extension signed by myself in dev mode.

When I see this error instead of restarting my whole browser with 10000 tabs I just drag 'and' drop the crx file and the error goes away add all my previous sessions are back.

I was asking to myself if you could add some kind of "observer" to know when the extension have no longer access to the indexDB and start automatically the re-installation process ?

[mikelei8291]

@mikhoul This issue is fixed, so it is closed. If you have any other issue please open a new one instead of posting unrelated contents here.