The text in transaction lifetime about "when a transaction can be started" doesn't define an algorithm (unlike e.g. web locks). Instead, it just defines preconditions. Specifically for this case:

• ... As long as a read-only transaction is running, the data that the implementation returns through requests created with that transaction must remain constant ...

Which is then followed by the note:

There are a number of ways that an implementation can ensure this. The implementation could prevent any read/write transaction, whose scope overlaps the scope of the read-only transaction, from starting until the read-only transaction finishes. Or the implementation could allow the read-only transaction to see a snapshot of the contents of the object stores which is taken when the read-only transaction started.

Chrome implemented snapshots, and therefore allowed a readwrite transaction to start even while a readonly transaction overlapping scope was still running. e.g.

const tx1 = db.transaction('store', 'readonly');
const tx2 = db.transaction('store', 'readwrite');

Both tx1 and tx2 could start immediately; operations within tx1 would see a snapshot of the data.

Other engines (Firefox, Safari, Edge) did not implement this; tx2 would not start until tx1 finished.

Chrome is changing this as part of a rework of the implementation; we actually had a non-WPT test asserting this behavior, which broke.

Following this change, all engines will behave the same way - the readonly transactions must finish before the readwrite transaction can start. Should we codify that in the spec and WPTs?