Issue metadata
Sign in to add a comment
|
indexedDB put() does not work in the last Canary
Reported by
vsemozhe...@gmail.com,
Dec 16 2016
|
||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2953.0 Safari/537.36
Steps to reproduce the problem:
Run this code via the Console or a Sources Script Snippet:
/********************************************************/
const openRequest = indexedDB.open('testIDB', 1);
openRequest.onerror = (evt) => {
console.error(evt.target.error);
};
openRequest.onupgradeneeded = (evt) => {
evt.target.result.createObjectStore('testSTORE');
};
openRequest.onsuccess = (evt) => {
const db = evt.target.result;
db.onerror = (evt) => {
console.error(evt.target.error);
db.close();
};
db.transaction('testSTORE', 'readwrite').objectStore('testSTORE')
.put('testVAL', 'testKEY').onsuccess = () => {
db.transaction('testSTORE', 'readonly').objectStore('testSTORE')
.get('testKEY').onsuccess = (evt) => {
console.log(`testKEY: ${evt.target.result}`);
db.close();
};
};
};
/********************************************************/
What is the expected behavior?
Console output: "testKEY: testVAL".
You can see it in the last Firefox (53.0a1 (2016-12-16) (64-bit)) and the last Google Chrome Dev channel build (57.0.2950.4 dev (64-bit)).
You can also look in the Application -> IndexedDB and see the key and the value in the testIDB -> testSTORE.
What went wrong?
In the last Canary build (57.0.2953.0 canary (64-bit)) the output is "testKEY: undefined". You can also look in the Application -> IndexedDB and see that testSTORE in testIDB is created, but empty.
Did this work before? Yes 57.0.2950.4 dev (64-bit)
Does this work in other browsers? Yes
Chrome version: 57.0.2953.0 Channel: canary
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 24.0.0.189
I've successfully used a bookmarklet with a code like this in Google Chrome during several years.
,
Dec 17 2016
In diff between 57.0.2950.4 and 57.0.2953.0 there are at least 5 indexedDB-related changes: https://chromium.googlesource.com/chromium/src/+log/57.0.2950.4..57.0.2953.0?pretty=fuller&n=10000
,
Dec 19 2016
,
Dec 19 2016
,
Dec 19 2016
Tested on windows 10 , windows 7 using chrome latest canary M57 #57.0.2955.0 and issue is not reproduced. The output of the given code in comment#0 in console is "testKEY: testVAL" as expected. Attached screenshot for reference. @vsemozhetbyt -- Could you please check and let us know if this is the intended behavior or correct us if we have missed out anything. Thanks!
,
Dec 19 2016
I've tried to disable brotli-encoding and to enable PreferHtmlOverPlugins to get command line matched with your screenshot, but the bug remains.
,
Dec 19 2016
Are you sure the first transaction is committing? Add in listeners for 'complete' and 'abort' events on the transaction. You might see this behavior if the first transaction (the one with the put()) is aborting so the record does not appear when the second transaction (the one with the get()) runs. I don't know why it would be aborting consistently, though, if the upgrade succeeds. (i.e. we're not dealing with a quota issue) The only other guess I have at the moment is that a bug was introduced where the readonly transaction is allowed to start before the readwrite transaction commits; we'd have seen test failures in that case, though.
,
Dec 19 2016
If any transaction is not committing, the `console.log` should not be fired, should it? `console.log` is contained in the second transaction (`get`) 'onsuccess' event callback, and the second transaction is contained in the first transaction (`put`) 'onsuccess' event callback. If the first one failed, neither `get` nor `console.log` should be fired, right? Maybe I miss something or do not understand API right. Could you suppose another code to check your assumptions?
,
Dec 19 2016
It seems you are right. I've run this code:
/********************************************************/
const openRequest = indexedDB.open('testIDB', 1);
openRequest.onerror = (evt) => {
console.error(evt.target.error);
};
openRequest.onupgradeneeded = (evt) => {
evt.target.result.createObjectStore('testSTORE');
};
openRequest.onsuccess = (evt) => {
const db = evt.target.result;
db.onerror = (evt) => {
console.error(evt.target.error);
db.close();
};
const transaction = db.transaction('testSTORE', 'readwrite');
transaction.oncomplete = function(event) { console.log(`put complete: `, event); };
transaction.onabort = function(event) { console.log(`put aborted: `, event); };
transaction.onerror = function(event) { console.log(`put error: `, event); };
transaction.objectStore('testSTORE')
.put('testVAL', 'testKEY').onsuccess = () => {
db.transaction('testSTORE', 'readonly').objectStore('testSTORE')
.get('testKEY').onsuccess = (evt) => {
console.log(`testKEY: ${evt.target.result}`);
db.close();
};
};
};
/********************************************************/
And here is the output in the screenshot. Should I unfold any event sub-objects for you?
,
Dec 19 2016
Look at transaction.error.name and transaction.error.message in the onabort handler.
,
Dec 19 2016
transaction.onabort = function(event) { console.log(`put aborted: ${transaction.error.name}, ${transaction.error.message}.`); };
"put aborted: QuotaExceededError, ."
,
Dec 20 2016
So is this a bug or some local misconfiguration? I have ~ 1.5 GB free space on the disk and there is no problem with 57.0.2950.4 dev.
,
Dec 20 2016
,
Dec 22 2016
In 57.0.2959.0 Canary (64-bit) the bug has disappeared.
,
Dec 23 2016
@vsemozhetbyt--As per comment #15 , can we close the issue . Could you please confirm us.
,
Dec 23 2016
For me, the bug has gone, so if nobody else confirms it, maybe it could be closed.
,
Dec 26 2016
Thanks for the update, closing the issue as per C#17. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by vsemozhe...@gmail.com
, Dec 16 2016