1833219 - IndexedDB transactions will commit partial data in some situations

Status: NEW

(Core :: Storage: IndexedDB, defect)

Description

[Diggory]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/113.0

Steps to reproduce:

The steps to reproduce:

• Begin an IndexedDB transaction
• Perform one mutation
• Perform one of the following operations:
  • Break into the debugger and then resume
  • Call "alert()" or "confirm()"
• Perform a second operation

The IndexedDB API is a little convoluted so I have created a reproduction on JSFiddle:
https://jsfiddle.net/x09kc2bz/

The transaction in this reproduction is intended to increment the value by 2 each time, so no odd value should ever be observed. However, if you check the "break transaction" option, and then try it, you will see that the transaction partially commits and an odd value is persisted.

Actual results:

When the synchronous operation occurs (even if this is breaking into the debugger!) firefox erroneously commits the transaction in a partial state.

Expected results:

The transaction should either fully commit or be rolled back.

I see no reason why "alert()" or "confirm()" should be allowed within an IndexedDB transaction, so the best option for those functions might be to immediately revert the transaction.

However, the bigger problem is when breaking into the debugger - I used the "debugger" statement in the repro for simplicitly, but this is a problem even if the debugger is triggered on a completely unrelated piece of code. It's not acceptable that breaking into the debugger in one piece of code should cause data corruption elsewhere, and ideally it shouldn't cause the transaction to fail at all.

When I tested this in chrome, the transaction commits successfully in all cases.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Storage: IndexedDB' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: repro.html

The JSFiddle is super helpful, thank you very much! (Converting it to a static HTML for longer archive)

Harveer has been touching IndexedDB recently. Hi Harveer, can you take a look? Thanks!

Comment 3

[Harveer Singh]

Yes, I could reproduce it. Seems like the onsuccess handler for req2.onsuccess was not called after the alert message was generated. So, we never ran the second put operation which incremented the counter by 2. This doesn't seems like by design, I need to investigate this bit further.