Unknown issue on Safari, with Potential route of Discovery about drift

[simolus3]

Thanks for the report, I'll try to reproduce this with an example from this repository.

However, storage doesn't function as anticipated.

Is it just completely broken without giving any error message or is there more that might be relevant?

In private mode, additional missing features are noted:

Does it also pick sharedIndexedDb there?

[Dall127]

it does pick sharedIndexedDb

I believe that it successfully creates the Database (i.e. in my debug panel I can see the expected db got created)

though afterwards, nothing is getting stored. Normally I'd get a dropdown showing at least a little of what got stored,
(as shown on pre-migration)

After migration

So I'm making the assumption that nothing is getting stored. My initial (blindly attempting) pull request's goal was to see if perhaps there was an issue with utf-8, as for why we discussed I don't think that's the case.

output from private mode: Using WasmStorageImplementation.sharedIndexedDb due to missing browser features: {MissingBrowserFeature.dedicatedWorkersInSharedWorkers, MissingBrowserFeature.fileSystemAccess, MissingBrowserFeature.sharedArrayBuffers}

Alls to say, my bet would be that there's something fishy with the fileSystemAccess on Safari if the lack thereof makes the implementation work

[Dall127]

Update: I think the initial trail might have been a little misleading; there's two new things that might give you clue to what's up.
I've found potential solution for the Safari normal mode issue. This might have been a migration-to-wasm issue, though I was sure to rename the db after migrating. Not completely sure.

However, there's a new twist in Safari's private mode: storage works correctly on the first load, but fails on subsequent reloads. This is a different layer to the problem, suggesting an issue with Safari's handling of data storage and retrieval across different browsing sessions. It doesn't occur on private mode in other browsers.

@simolus3 , If you have a discord, I can PM you a link to the site with the issue. It'll be a black box, but at least you'll be able see what states get you into what

[simolus3]

Sure, my Discord username is simonbinder

[SleepySquash]

I might add some strange things discovered in Safari 17.4.1. It seems like deploying web application with Cross-Origin-Embedder-Policy header set to require-corp breaks the WasmDatabase entirely (Safari only, other browsers have no issues). The application initializes and works perfectly fine with the first run, however on each following page refresh the drift throws the error in the console, unable to initialize:

Note: I'm building the examples/app application (cd examples/app && dart run build_runner build && flutter build web) and then deploying it with the following command:

dhttpd '--headers=Cross-Origin-Embedder-Policy=require-corp;Cross-Origin-Opener-Policy=same-origin' --path build/web/

The drift picks IndexedDB for storage:

Using WasmStorageImplementation.sharedIndexedDb due to unsupported browser features: {MissingBrowserFeature.dedicatedWorkersInSharedWorkers}

And the culprit seems to be the IndexedDB's database not being populated, as like WasmDatabase doesn't have the write access (it should contain blocks, etc):

What's even more strange is the fact that deploying application without the COEP/COOP headers works fine and even deploying the COEP with credentialless works fine! However, when COEP is set to credentialless, the drift seems to consider SharedArrayBuffers as being unavailable:

Using WasmStorageImplementation.sharedIndexedDb due to unsupported browser features: {MissingBrowserFeature.dedicatedWorkersInSharedWorkers, MissingBrowserFeature.sharedArrayBuffers}

Yet I can confirm the headers are set:

Perhaps Safari with COEP set to require-corp needs some additional deployment configuration? I'll try to investigate this a bit and leave a comment, if something is up.

UPD. The bug mentioned at https://drift.simonbinder.eu/web/#additional-headers might be related, however I'm not sure: https://bugs.webkit.org/show_bug.cgi?id=254065. Also it seems to have RESOLVED FIXED status.

[simolus3]

Thanks for the report! Did you already have a database from a previous run in the first screenshot? Drift should pick opfsLocks here, unless it detects that the IndexedDB database already exists (so that no data is lost).

However, when COEP is set to credentialless, the drift seems to consider SharedArrayBuffers as being unavailable:

When I tried that, crossOriginIsolated also reported false in the console - so shared buffers really are unavailable.

The problem, I think, comes from here:

drift/drift/lib/src/web/wasm_setup/shared.dart

Lines 116 to 139 in 2d870a6

	/// Returns whether an drift-wasm database with the given [databaseName] exists.
	Future<bool> checkIndexedDbExists(String databaseName) async {
	bool? indexedDbExists;
	try {
	final idb = globalContext['indexedDB'] as IDBFactory;
	final openRequest = idb.open(databaseName, 1);
	openRequest.onupgradeneeded = (IDBVersionChangeEvent event) {
	// If there's an upgrade, we're going from 0 to 1 - the database doesn't
	// exist! Abort the transaction so that we don't create it here.
	openRequest.transaction!.abort();
	indexedDbExists = false;
	}.toJS;
	final database = await openRequest.complete<IDBDatabase>();
	indexedDbExists ??= true;
	database.close();
	} catch (_) {
	// May throw due to us aborting in the upgrade callback.
	}
	return indexedDbExists ?? false;
	}

We're checking whether an IndexedDB database exists because, if it does, we don't want to use OPFS even it is available. The problem is that (despite aborting the transaction) we seem to create the database inadvertently with that check. That's a big problem, because it now means that as soon as we reach a state where OPFS doesn't exist/is unavailable, we'll try to use that broken database.

Most browsers support indexedDb.databases though, I'll migrate the check to that if it's supported to avoid creating the database here.

[simolus3]

So I've fixed that in 996176d, but that only prevents new versions from accidentally creating a bogus database. Depending on how widespread this problem is we may have to bump the schema version for IndexedDB and create the stores if they don't exist.