[whatwg] RFC: Alternatives to storage mutex for cookies and localStorage
Jeremy Orlow
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>
> 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-0002.htm>
More information about the whatwg
mailing list