database format

The database is an sqlite3 database, accessed via the WebSql API. This is deprecated (and was never adopted as a web standard) but is supported by at least Chromium and Webkit-based browsers for the time being. Supposedly this will last "while there is active use of it". Given that the "replacement" IndexedDB offers no SQL, and the current code makes significant use of SQL, it would be a major reprogramming effort to convert to IndexedDB.

Manifest Version 2 program structure

database

The background page of the extension provides the database access point. Content pages and extension pages pass messages to the background page, which does the database operation and then uses the callback to return the result (if any)

Manifest Version 3 issues

The background "page" no longer exists as such and is replaced by a "worker script". This has two major impacts:

1. the script is transient, so values cannot be retained across calls
2. the worker script has a different scope - ServiceWorkerGlobalScope rather than Window.

There are three major activities that the background page is responsible for under V2 that need to be modified to work under V3: user options, generic functions, and database. These need to be accommodated via new code:

user settings

These currently only last while the extension is running. They can be replaced, (and made persistent) by storage objects. Note, this is not Window.localStorage, which is restricted to each page's origin, but chrome.storage.

Most of these settings are used only on the page that handles display/export of results and so do not even need to be globally accessible.

Another option is that they are saved in the database itself for backup/portability, although at the moment there are no settings that are particularly vital.

generic functions

were stored in the background page and accessed via the chrome.extension.getBackgroundPage().function(args). Even if this does reload the worker script (docs are rather vague on this), I suspect it will still suffer from the other problems detailed in relation to database (for those functions accessing the DB). Manifest V3 migration checklist states that The adoption of service workers in Manifest V3 isn't compatible with methods like chrome.runtime.getBackgroundPage(), chrome.extension.getBackgroundPage() ...

Many of them are used only in the results presentation page and can simply be moved into that supporting code. Others can be duplicated as required.

Database operations

The worker scope is more limited that the previous window scope of the background page and for example has no access to the WebSQL interface (There is supposed to be a workerUtils scope but that was either never implemented or has been removed).

Some options to get around this problem are:

• the worker script creates a transient page/tab that handles the DB processes. A _transient _page could be kept in the background rather than flashing up each time, although it would require creation/destruction on every DB transaction, along with reopening DB access for every transaction. This seems to be the direction a direct port would take, but it seems nasty and horribly inefficient.
• the worker script creates a persistent page/tab that handles the DB processes. A persistent page seems ugly, with a blank tab hanging around all the time.
• the current page that presents results and provides export capabilties could also handle the DB request messages. It would have to be fired up automatically and cope with accidentally being shut down or, worse still, duplicated.
• each page could have its own access to the DB. The sqlite3 code can handle multithreaded access through a locking mechanism. This has what seems to be a fatal problem, in that the database is tied to the origin of the page. This means some pages use the db in the context of the extension, while others (e.g. the 'DNA relatives' page) use a db in the context of the 23 and me web site -_ the content scripts have** no access** to the extension db._

Some experimentation between the second and third options may be required to determine the least undesirable way to make it work.

Other possibilities

The officially supported storage API, indexedDB is available in different scopes, both worker script and windows.

• it still has the same "same origin" policy as webSQL, which means content scripts and extension pages cannot access the same database.
• it also has the same transient life issue if the worker script was the data assess portal: needing to repoen the connection for every transaction
• because indexedDB offers no SQL it would be a bit of a nightmare recoding for the display routines, but should be OK if we restricted the new code to just providing CSV output files.
• there are 3rd party SQL API layers (jsStore in conjunction with sqlWeb ) that can work with indexedDB, but it is nothing like a plug-in replacement for the current webSQL and looks like a major rewrite would be needed.

DB operation efficiency

See the page on testing timing of DB Operations