Specific check was:

[16908:16975:0317/130054:FATAL:storage_monitor.cc(388)] Check failed: false.

And it's the filter.origin.is_empty() test that's returning true.

...

Also hit this on a later run when profile wasn't cleared:

[18244:18272:0317/131035:FATAL:client_usage_tracker.cc(151)] Check failed: cached_usage_by_host_[host][origin] >= 0 (-3 vs. 0)
#0 0x7f6052912b3e base::debug::StackTrace::StackTrace()
#1 0x7f605296df6f logging::LogMessage::~LogMessage()
#2 0x7f604798e0c9 storage::ClientUsageTracker::UpdateUsageCache()
#3 0x7f60479ec121 storage::UsageTracker::UpdateUsageCache()
#4 0x7f60479aba1d storage::QuotaManager::NotifyStorageModifiedInternal()
#5 0x7f60479ab8a2 storage::QuotaManager::NotifyStorageModified()
#6 0x7f60479d0274 storage::QuotaManagerProxy::NotifyStorageModified()

I'm not sure what's going on, because content_browsertests that use file: URLs pass, and StorageMonitor is seeing 'file:///' as the origin's spec.

Blink sees SecurityOrigin as null when coming from full Chrome/manually entered URL, but file:// from content_browsertests. Ugh...

Introduced by https://codereview.chromium.org/1755343002 (so my bad). Prior to that CL, StorageMonitor sees 'file:///'.

The DatabaseIdentifier minted in Blink for this case was "file__0", which Chromium would regenerate into "file:///". 

Since I updated the Cache Storage API too I tried `window.caches.open('foo')` from a file:/// page - that get terminated via bad_message (reason 94) now.

The SecurityOrigins in question from blink are ("file", "", 0), not unique but with m_blockLocalAccessFromLocalOrigin true (apparently), so toString() yields "null", WebStringToGURL is yielding an !is_valid GURL and it's downhill from there.

Assuming we don't want to deny access to storage from these pages, one quick fix would be to add e.g. blink::SecurityOriginToGURL() used specifically for these conversions, pending end-to-end url::Origin usage (which would need to permeate into Quota), or just special-case the conversions for these APIs. I'll stick up a CL for comments.

... and the right answer may be "we should deny access from these pages" but that requires discussion; right now the canAccessXXX() checks just look at m_isUnique and not m_blockLocalAccessFromLocalOrigin.

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

commit 5721760f19e829770503b2aa4e51ff76848f2270
Author: jsbell <jsbell@chromium.org>
Date: Tue Mar 22 16:42:19 2016

Fix effective Origin URLs for IDB + Cache for file:/// pages

This is a terrible, horrible, no good, very bad hack.

Previously, storage APIs (notable, Indexed DB, Cache Storage) would
pass the origins they operated on from Blink to Chromium's
content/browser as a serialization done through
SecurityOrigin->DatabaseIdentifier->String->IPC->String->GURL. That
was simplified to SecurityOrigin->String->GURL->IPC. A side effect of
this was that pages browsed as file:// URLs would end up as invalid
GURLs due to stricter checks in the SecurityOrigin->String step.
Special case that conversion to restore the previous behavior.

R=michaeln@chromium.org,mkwst@chromium.org
BUG= 595840 

Review URL: https://codereview.chromium.org/1810193002

Cr-Commit-Position: refs/heads/master@{#382587}

[modify] https://crrev.com/5721760f19e829770503b2aa4e51ff76848f2270/content/child/indexed_db/webidbfactory_impl.cc
[add] https://crrev.com/5721760f19e829770503b2aa4e51ff76848f2270/content/child/storage_util.cc
[add] https://crrev.com/5721760f19e829770503b2aa4e51ff76848f2270/content/child/storage_util.h
[modify] https://crrev.com/5721760f19e829770503b2aa4e51ff76848f2270/content/content_child.gypi
[modify] https://crrev.com/5721760f19e829770503b2aa4e51ff76848f2270/content/renderer/renderer_blink_platform_impl.cc

I'd be happier with tests, but apparently they didn't catch this before.