W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

[whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

From: Jeremy Orlow <jorlow@chromium.org>
Date: Tue, 8 Sep 2009 18:42:53 +0900
Message-ID: <5dd9e5c50909080242s2ecb9369pa30495cb713cef95@mail.gmail.com>
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>
> wrote:
> > 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
> cookies
> > can't easily be done with a mutex per domain. Ian pointed out this
> approach
> > breaks if you can make synchronous script calls across origins (e.g.
> across
> > 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
> mutex?
>
> 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
> this.
>

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
implicitly released!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090908/29277b64/attachment-0001.htm>
Received on Tuesday, 8 September 2009 02:42:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC