I created a video but it is too big to upload here (25mb):
https://drive.google.com/a/google.com/file/d/0ByifqR9x_QRSOGd3TWlneFpmTjg/view?usp=sharing

The "type 2" in the log is kStorageTypeSyncable - that type should only be available to chrome apps/extensions. Unrelated?

I was able to reproduce this issue with Chrome Dev with the default set of corp extensions and with a Chromium build without any extensions, so I don't think the data that is left is related to apps or extensions

jsbell@: Could you take another look? As described in #6, I don't think this is related to extensions. I don't know how these entries got to have "type 2" but I think that there is an issue with filesystem entries created by regular websites.

Bleah, tip-of-tree chrome://settings/siteData is crashing - filed  issue 774586 

Commenting that out... yeah, I can repro the logging locally with both yahoo.com and localhost with a filesystem thingy...

[85562:85592:1013/112256.894350:ERROR:storage_partition_impl.cc(131)] Couldn't remove data of type 1 for origin http://localhost:8888/. Status: 11
[85562:85592:1013/112256.894778:ERROR:storage_partition_impl.cc(131)] Couldn't remove data of type 1 for origin https://www.yahoo.com/. Status: 11
[85562:85592:1013/112256.899035:ERROR:storage_partition_impl.cc(131)] Couldn't remove data of type 2 for origin http://localhost:8888/. Status: 11
[85562:85592:1013/112256.899191:ERROR:storage_partition_impl.cc(131)] Couldn't remove data of type 2 for origin https://www.yahoo.com/. Status: 11

Note that type 1 is kStorageTypePersistent, which is NOT what localhost was using. I think the logging is irrelevant, i.e. it's just saying "there's nothing of this type to remove", but I still need to verify.

I'll keep digging.

Weird. Now I've gotten into a state where the quota database thinks there's nothing in the yahoo.com origin (so it doesn't try and delete anything chrome://settings/clearBrowserData) but there is filesystem data (so it shows up on chrome://settings/siteData). 

In this state, hitting the trash button on chrome://settings/siteData for the site adds quota entries for the origin of the various types (temporary, persistent, syncable - so that's where those log entries were coming from).

So at least two bugs here:

(1) Quota database can get out of sync with what's enumerated
(2) siteData causes bogus quota entries to get added

Also, once #2 has happened, chrome://settings/clearBrowserData won't remove those entries (hence the logging) so you're stuck until the database is manually wiped.

#2 is understood and I've got a fix up for review now (see  issue 774666 ) but on its own it doesn't explain #1.

Figured out #1. If you create a filesystem and never write anything to it the quota database isn't updated, so chrome://settings/clearBrowserData doesn't know the origin has anything to delete, but chrome://settings/siteData will still enumerate/delete it

Repro:

(1) Save fs.html locally
(2) Run a local http server
(3) Load the file, e.g. http://localhost:8888/fs.html
(4) go to chrome://settings/clearBrowserData and delete cookies for all time.
(6) go to chrome://settings/siteData and observe that there are still filesystem entries for localhost

(Script can't ask "does a FS exist?" it can just re-create it. So I don't think it's a privacy leak that can be abused, but obviously we should fix.)

Deleted: fs.html 682 bytes

fs.html 682 bytes View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a279dce85c96a8d286fb907d48c2ae63204266db

commit a279dce85c96a8d286fb907d48c2ae63204266db
Author: Joshua Bell <jsbell@chromium.org>
Date: Mon Oct 23 23:00:12 2017

Ensure opening a sandboxed file system notifies the quota system

When a sandboxed file system is opened (via webkitRequestFileSystem())
the quota system must mark the origin as having content so
chrome://settings/clearBrowserData can clear it even if no files are
created. chrome://settings/siteData would enumerate it (and allow
deletion) regardless, but both should work.

Bug:  771623 
Change-Id: I304d2e12239123d061a0c2bc7ef4422657b26505
Reviewed-on: https://chromium-review.googlesource.com/720240
Reviewed-by: Taiju Tsuiki <tzik@chromium.org>
Reviewed-by: Michael Nordman <michaeln@chromium.org>
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510953}
[modify] https://crrev.com/a279dce85c96a8d286fb907d48c2ae63204266db/chrome/browser/sync_file_system/local/local_file_change_tracker_unittest.cc
[modify] https://crrev.com/a279dce85c96a8d286fb907d48c2ae63204266db/storage/browser/fileapi/sandbox_file_system_backend_delegate.cc
[modify] https://crrev.com/a279dce85c96a8d286fb907d48c2ae63204266db/storage/browser/fileapi/sandbox_file_system_backend_delegate.h
[modify] https://crrev.com/a279dce85c96a8d286fb907d48c2ae63204266db/storage/browser/fileapi/sandbox_file_system_backend_delegate_unittest.cc