Bug 77060

See thread: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0329.html Chromium port of WebKit behaves differently in these cases: If an insertion fails due to constraint violations or IO error, the key generator is not updated. trans.onerror = function(e) { e.preventDefault() }; store = db.createObjectStore("store1", { autoIncrement: true }); index = store.createIndex("index1", "ix", { unique: true }); store.put({ ix: "a"}); // Will get key 1 store.put({ ix: "a"}); // Will fail store.put({ ix: "b"}); // Will get key 2 -- Chromium/WebKit gets 3 .... Aborting a transaction rolls back any increases to the key generator which happened during the transaction. This is to make all rollbacks consistent since rollbacks that happen due to crash never has a chance to commit the increased key generator value. db.createObjectStore("store", { autoIncrement: true }); ... trans1 = db.transaction(["store"]); store_t1 = trans1.objectStore("store"); store_t1.put("a"); // Will get key 1 store_t1.put("b"); // Will get key 2 trans1.abort(); trans2 = db.transaction(["store"]); store_t2 = trans2.objectStore("store"); store_t2.put("c"); // Will get key 1 -- Chromium/WebKit gets 3 store_t2.put("d"); // Will get key 2 -- Chromium/WebKit gets 4 ..... In the former case, it appears that the failed put does not roll back the key generator. The uniqueness test should run before the key generator is used. In the latter case, it appears that the aborted transaction does not roll back the key generator. The key generator state should be included in the transaction scope.