On access to `self.caches`, Chrome checks if the context is sandboxed; if so it throws.

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/cachestorage/GlobalCacheStorage.cpp?l=48

The test assumes that global.caches will succeed but global.caches.open() will reject.

https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/external/wpt/service-workers/cache-storage/resources/iframe.html?l=8

HTML has:
> https://html.spec.whatwg.org/multipage/browsers.html#sandboxing
> https://html.spec.whatwg.org/multipage/browsers.html#sandboxed-origin-browsing-context-flag

... which says that the 'sandbox' attribute w/o 'allow-same-origin' "forces content into a unique origin"

IDL defines [SecureContext]:

> https://heycam.github.io/webidl/#SecureContext
> https://heycam.github.io/webidl/#dfn-exposed

... which leads to:

https://w3c.github.io/webappsec-secure-contexts/#settings-object
https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy

... which tells me that unique (opaque) origins shouldn't be trustworthy and thus not secure and thus `self.caches` should simply be not present i.e. not even throw.

So... I updated `caches` to have [SecureContext]. That did not make the API disappear in this sandboxed iframe case. Looks like we have a bit more work to do on SecureContext.

(The test would still fail in exactly the same way it does now, but when I tried to fix the test to expect caches to be missing it wasn't!)

Sandboxed frames that were loaded from a trustworthy URL can be secure contexts. See steps 3 and 4 of https://w3c.github.io/webappsec-secure-contexts/#is-settings-object-contextually-secure.