New issue
Advanced search Search tips

Issue 628626 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

Clearing Chrome cache data corrupts IndexedDB state

Reported by matthias...@googlemail.com, Jul 15 2016

Issue description

Chrome Version       : 51.0.2704.106 (Official Build) m (64-bit)
URLs (if applicable) :
Other browsers tested:   
    Firefox: OK (47)

What steps will reproduce the problem?
(1) open IndexedDB database indexedDB.open(DB_NAME, DB_VERSION)
(2) create objectstore during onupgradeneeded callback
(3) clear browser cache
(4) reopen the IndexedDB database created in step 1 with the same version number

What is the expected result?
Database opens with an empty (no records) objectstore created in step 2 and queries to this object store run succesfully with empty result set.

What happens instead?
Database opens succesfully but the objectstore (from step 2) is missing which results in 'Failed to execute 'transaction' on 'IDBDatabase': One of the specified object stores was not found.' when querying the database. It is also not possible to create a new object store on application start since this has to be done from within 'onupgradeneeded' callback (which is not fired) otherwise resulting in 'InvalidStateError - The method [is] not called from a versionchange transaction callback'

 
Labels: Te-NeedsFurtherTriage
Components: Blink>Storage>IndexedDB
To be more precise with regards to step 3 (clearing browser cache):
The issue occurs when only default check boxes are set in Chrome's cache clearing dialog (see attached image). However, when additionally checking 'Hosted app data' then everything works fine as expected. Furthermore, I experience the same behavior on Mobile Chrome on my Android (6.0.1) mobile phone.
chrome_cache_clear.jpg
43.6 KB View Download

Comment 4 by jsb...@chromium.org, Jul 19 2016

Labels: Needs-Feedback
When "Cookies and other site and plugin data" is checked, Indexed DB (and other site data) is cleared.

What you describe is what I'd expect if you had no "upgradeneeded" handler when opening the database after clearing. For example:

(1) execute this script:

var r = indexedDB.open('db');
r.onupgradeneeded = function(e) {
  console.log('upgrading from', e.oldVersion, 'to', e.newVersion);
  var db = r.result;
  db.createObjectStore('s');
};
r.onsuccess = function() {
  try { 
    db.transaction('s');
    console.log('ok');
  } catch (e) {
    console.log('no such object store');
  }
};

(2) clear browsing data

(3) execute this

var r = indexedDB.open('db');
// r.onupgradeneeded = function(e) {
//  console.log('upgrading from', e.oldVersion, 'to', e.newVersion);
//  var db = r.result;
//  db.createObjectStore('s');
// };
r.onsuccess = function() {
  try { 
    db.transaction('s');
    console.log('ok');
  } catch (e) {
    console.log('no such object store');
  }
};

Note that in the second code block there is no "upgradeneeded" handler; the database will open but no object stores will be created. This sounds like what you're observing, and is the correct behavior for the API.

Can you provide example code used before/after clearing that demonstrates the problem you're seeing, if it doesn't match the above explanation?

At first: Sorry for the inconvenience. 
I figured out what caused the issue: In my application there is only a startup check of whether a database upgrade is needed. However, there is a 'beforeunload' handler on my page for storing current application state in indexedDB to be able to restore the state on next startup. Now, when I clear the cache (database and its objectstores are gone) the 'beforeunload' handler is triggered trying to open the respective database objectstore without having set an "upgradeneeded" handler and then ... CRASH.

Thanks for pointing in the right direction and sorry for wasting your time. This way, I guess the issue is solved (no bug just a dumb user).

Comment 6 by jsb...@chromium.org, Jul 20 2016

Status: WontFix (was: Unconfirmed)
No problem - glad to help!

Sign in to add a comment