[whatwg] RFC: Alternatives to storage mutex for cookies and localStorage
jorlow at chromium.org
Tue Sep 8 02:42:53 PDT 2009
On Tue, Sep 8, 2009 at 6:38 PM, Aaron Boodman <aa at google.com> wrote:
> On Tue, Sep 8, 2009 at 2:02 AM, Robert O'Callahan<robert at ocallahan.org>
> > Looking back over previous threads on the storage mutex, I can't seem to
> > remember or find the reason that implementing the storage mutex for
> > can't easily be done with a mutex per domain. Ian pointed out this
> > breaks if you can make synchronous script calls across origins (e.g.
> > IFRAME boundaries), but can you actually make such calls? Or if you can
> > (NPAPI?), can we just declare that those APIs release the storage mutex?
> I believe that synchronous cross-origin calls are possible a variety
> of ways. Here is one way I found with a quick test: Resize an iframe
> element. window.onresize is fired synchronously inside the frame. I
> bet there are others.
> > I know that setting document.domain makes this tricky because it
> > synchronously enables new cross-domain interactions, but can't we handle
> > that by declaring that setting document.domain releases the storage
> All of these different ways that the storage mutex gets implicitly
> released lead to weird behavior in edge cases. In my opinion, it would
> be better to fix the API in a clean way than keep patching it like
I definitely agree. Implicitly releasing the lock is terrible. (We should
at the _very least_ create some way for people to know when it's been
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg