872873 - ConstraintError in IndexedDB should not throw error

Status: RESOLVED WORKSFORME

(Core :: Storage: IndexedDB, defect)

Description

[Kyaw Tun]

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

Comment 1

[Potch]

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.

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Testcase?

Comment 3

[Potch [:potch]]

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

[Potch [:potch]]

Making a testcase.

Comment 5

[Potch [:potch]]

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.

Comment 6

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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

[Yonggang Luo]

This is weird, so we need always preventDefault, or it will getting to the window.

Comment 8

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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.