To update the display in the DevTools' Storage Inspector once a database change happens there need to be APIs tracking those changes. (In reply to Jarda Snajdr [:jsnajdr] from bug 1268460 comment #8) > Because IndexedDB has no API for observing changes, we need to implement its > poor man's replacement: the "onDatabaseRemoved" notification. It takes care > of removing the database from actor.hostVsStores, and firing the > "stores-update" event. After we add more editing capabilites to IndexedDB > actor, it will evolve into something like "onCookieChanged" for cookies. These APIs should cover the following (Jarda, please complete the list if I missed something): - database creation - database removal - database opening ? - database closing ? - data addition - data removal - index creation - index removal How those APIs are implemented still needs to be discussed. One solution could be via nsIObserverService like it's used for network requests[1], for example. Sebastian https://developer.mozilla.org/en-US/docs/Setting_HTTP_request_headers

Note that bug 1059724 doesn't cover - database creation - database removal - database opening ? - database closing ? However database removal you can get notified about by keeping a reference to an opened database and listening to "versionchange" events.

Oh, and you can also get - index creation - index removal - objectStore creation - objectStore removal notifications the same way. I.e. keep the database open and listen for versionchange events. Once you get a versionchange event, close the database and immediately reopen it. Then you can diff the list of indexes and objectStores.

Thanks for the info, Jonas! (In reply to Jonas Sicking (:sicking) from comment #2) > Note that bug 1059724 doesn't cover > > - database creation > - database removal > - database opening ? > - database closing ? (In reply to Jonas Sicking (:sicking) from comment #3) > - index creation > - index removal > - objectStore creation > - objectStore removal Well, you mentioned it at least in bug 1059724 comment 1. FYI, I've created bug 1273802 for the Storage Inspector changes. Sebastian

(In reply to Jonas Sicking (:sicking) from comment #2) > Note that bug 1059724 doesn't cover > > - database creation > - database removal > - database opening ? > - database closing ? > > However database removal you can get notified about by keeping a reference > to an opened database and listening to "versionchange" events. Database creation event is needed if we want to display an up-to-date view of existing databases in the Storage Inspector. We don't really need to know about opening and closing. Storage Inspector shouldn't have any observable effects on the behavior of the inspected page, like causing "blocked" events to be fired at unexpected places. That's why I'm a bit concerned about the approach where we keep open references to all inspected databases. But if I can really avoid that by correctly handling "versionchange" events, as one comment in bug 1059724 says, then it's feasible. However, I think the most convenient API for Storage Inspector would be firing "idb-changed" events through nsIObserverService. It already listens for "cookie-changed" and "dom-storage2-changed" events to get updates about cookies and local/session storage.

While other ideas might have been floated earlier in that bug, bug 1059724 will only cover changes to data in objectStores (which in turn means that it also covers changes of data in indexes). Keep in mind that that bug is mainly aimed to expose functionality to websites, which have slightly different needs than devtools. Creation/removal of objectStores/indexes, and removal of databases, should already be observable through versionchange events. If you immediately close the database when the versionchange event is received, no "blocked" event should be fired. If they are, that's a bug that we should fix. I agree that devtools needs the ability to observe creation of new databases. I recommend filing a new bug specifically for that. Or de-duplicate and morph this one if you prefer.

Firing nsIObserverService events for db creation/removal/schemachange would be fine with me. I would imagine that's relatively easy to add. Though note that you need to keep the database open to observe changes to data. So if devtools keeping open databases causes "blocked" events to be fired, then we need to fix that either way.

(In reply to Jonas Sicking (:sicking) from comment #6) > While other ideas might have been floated earlier in that bug, bug 1059724 > will only cover changes to data in objectStores (which in turn means that it > also covers changes of data in indexes). Keep in mind that that bug is > mainly aimed to expose functionality to websites, which have slightly > different needs than devtools. > Creation/removal of objectStores/indexes, and removal of databases, should > already be observable through versionchange events. If you immediately close > the database when the versionchange event is received, no "blocked" event > should be fired. If they are, that's a bug that we should fix. It sounds a bit hacky to me having to close and reopen the database for this, though that sounds like it should work. > I agree that devtools needs the ability to observe creation of new > databases. I recommend filing a new bug specifically for that. Or > de-duplicate and morph this one if you prefer. I decided to de-duplicate it, because its the idea behind this was to provide an API for the DevTools and extensions and in order to keep the discussion visible. Sebastian

I think sending a notification containing simply the origin and the database name any time a database is added/removed/upgraded (i.e. has its version changed) should do the trick here.

(In case you're curious, btpp = "bug triage pilot program" and "fixlater" means "ideally we'll fix this in the next few months and if we don't it'll come up again in our triage process".)

(In reply to Andrew Overholt [:overholt] from comment #10) > (In case you're curious, btpp = "bug triage pilot program" and "fixlater" > means "ideally we'll fix this in the next few months and if we don't it'll > come up again in our triage process".) Thank you for the clarification, Andrew! Sebastian