ConstraintError in IndexedDB should not throw error

RESOLVED WORKSFORME

Status

()

Core
DOM: IndexedDB
RESOLVED WORKSFORME
5 years ago
3 years ago

People

(Reporter: Kyaw Tun, Unassigned)

Tracking

24 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.13 (KHTML, like Gecko) Chrome/24.0.1284.0 (Dart) Safari/537.13

Steps to reproduce:

put a record that violate database contraint causing ConstraintError.

In that case, onerror event callback is invoked with ConstraintError http://www.w3.org/TR/IndexedDB/#dfn-steps-for-storing-a-record-into-an-object-store request and abort the algorithm. But browser must not throw Error. 


Actual results:

Firefox throw error

See unit test http://dev.yathit.com/test/test_crud.html 
also compare with Chrome, it pass the unit test.


Expected results:

Firefox should not throw error
(Reporter)

Updated

5 years ago
Component: Untriaged → Web Apps

Updated

5 years ago
Component: Web Apps → DOM: IndexedDB
Product: Firefox → Core

Comment 1

4 years ago
Running into this issue building IndexedDB helpers. Firefox throws a constraintError in a way that doesn't seem to be able to be caught and suppressed. Nasty stuff.
Testcase?
Flags: needinfo?(mclaypotch)

Comment 3

4 years ago
To be clear, wrapping the offending code in a try...catch block does not catch the ConstraintError. There doesn't seem to be a way to continue gracefully after the error. It's a big problem.

Comment 4

4 years ago
Making a testcase.

Comment 5

4 years ago
Added testcase URL. The ConstraintError can't be caught (as it's the result of an async operation). Hard to build friendly abstractions on top of it. My intern's current project is trying to put promise wrappers around indexedDB, and this is an example of where the abstraction leaks.
Flags: needinfo?(mclaypotch)
You have to call |e.preventDefault()| in your onerror handler if you want to prevent the event from firing on the window and prevent your transaction from being aborted.

Comment 7

3 years ago
This is weird, so we need always preventDefault, or it will getting to the window.
Well, the big deal is that your transaction is normally aborted if you ever trigger an error event... This behavior is correct per spec, so closing.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.