mek@: Could this problem be solved in a similar way to  https://crbug.com/769425 ?

Oh, I mean similar to this bug:  https://crbug.com/679344 

A few things are going on with session storage:
- we don't seem to actually commit the deletion to disk if the area being cleared is still open (at least not immediately, the commit is scheduled for "later").
- even when the clearing is committed, I'm not convinced we also delete the "namepace-<namespaceid>-<origin>" keys, which are used to later retrieve sesion storage usage (I don't see SessionStorageDatabase::DeleteArea being called in the relevant codepath).
- deleting stuff is actually async, so I'm not sure how the UI decides when to refresh since afaik there isn't a "deletion is completed" signal

So definitely plenty of ways this can go wrong, but not sure what specifically is contributing to this particular situation.

Hopefully dmurph@s mojoification will help him understand how this works better than I currently understand it and/or result in fixing some of this.

agree that this is happening and it's a bug. dmurph@, can you take a look?

So the behavior of deleting origin data actually keeps around the metadata entry on disk for the namespace+origin. Since all use data is deleted, this is fine, but it does mean that it looks like it's still 'there'.

I'm going to mark this WAI, but if we feel differently about keeping our metadata on disk we can re-open.

The only data that 'leaks' on disk is the origins that are currently open and accessing session storage. If those tabs are closed, this should be deleted.

This is technically leaking browsing data briefly - deferring to dullweber about the importance of this. Referenced from 
https://bugs.chromium.org/p/chromium/issues/detail?id=772337

(The clear browsing data tool will delete all data, but leave the metadata. Then, when browser is restarted, the old metadata should be cleared. But you can see the origins.)

One way to solve this:

Have a namespace state of 'cleared & not written'. Then when the first thing gets written (or if a clone happens), then populate it. This will only optimize a 'root' namespace, any cloned-to namespaces will have to have populated metadata for the refcounting to work.

Then when an origin is cleared, that namespace case be totally wiped out, including metadata, and put into this state.

Hm, I tried the following:
1. Create sessionstorage on example.com
2. Close the tab of example.com
3. Clear all cookies through CBD
4. Close Chrome

I still had an "namespace-154fc596_d144_44bf_a026_dbb215f86f97-http://example.com/" entry in leveldb afterwards. 
I can't really follow your suggestion above.
Why do we still need that entry? Could we just remove it when sessionstorage is deleted?

So basically we are keeping track of the currently open tabs (or tabs that we are saving for restore).

That information basically says - there is storage open with namespace "154fc596_d144_44bf_a026_dbb215f86f97" and origin "http://example.com/", and it's data map has an id "value" (probably 1).

The system assumes its in-memory representation of namespaces & origins that are open matches the on-disk representation. Special-casing the need to delete origin data would be adding some complexity to an already pretty complex system :/

If this is necessary for CBD promises, then we can try to add it to our queue

When sessionstorage for an origin gets removed, could we remove the in-memory and on-disk entries? That way there wouldn't be any inconsistency.

For ClearBrowsingData we try to remove data from disk when it gets deleted, so this is an issue where it would be great if it gets fixed ;)