API exposure/behavior for unique origins? #41
Comments
|
(nit: they are opaque origins, not unique origins; for example a sandboxed iframe can still possibly create workers that (should) share the same opaque origin with the window) |
|
Yeah sounds good. Are you writing tests by any chance? @shuangMoz do you know if we have tests for this? |
|
Yeah, I'll put up a PR for tests (it'll be a few days). |
|
Tests over at web-platform-tests/wpt#4919 |
|
Conversation over on the test PR have leaned towards (1) rejecting with (2) TypeError. |
annevk
added a commit
that referenced
this issue
Feb 23, 2017
Also consistently queue a task to reject and resolve promises from in parallel steps. Tests: web-platform-tests/wpt#4919. Fixes #41.
annevk
added a commit
that referenced
this issue
Feb 23, 2017
Also consistently queue a task to reject and resolve promises from in parallel steps. Tests: web-platform-tests/wpt#4919. Fixes #41.
annevk
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Feb 23, 2017
Entry points (persist(), persisted(), estimate()) should reject in opaque origins (e.g., sandboxed iframes). See whatwg/storage#41.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sandboxed iframes end up with unique opaque origins. We should define the behavior of the API here.
One option would be to simply reject on any API call (
persist(),estimate(), etc). Chrome currently does this, and it's per spec for other storage APIs (localStorage, etc). Indexed DB does this too in Chrome (not sure that's specified anywhere)Another would be to introduce an analogue to
[SecureContext]that removes the API in unique opaque origins.Or we could let unique opaque origins have some ephemeral storage, with lifetime bound to the browsing context or some such. (But please no...)
The text was updated successfully, but these errors were encountered: