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

[whatwg] Storage events

From: Darin Fisher <darin@chromium.org>
Date: Thu, 15 Oct 2009 12:21:05 -0700
Message-ID: <bd8f24d20910151221pf87e752l2aaee369d4aee45b@mail.gmail.com>
On Thu, Oct 15, 2009 at 11:37 AM, Jeremy Orlow <jorlow at chromium.org> wrote:

> I'd like to propose we remove the "source" attribute from storage events.
>  (http://dev.w3.org/html5/webstorage/#the-storage-event)
> In Chrome, we cannot provide access to a window object unless it's in the
> same process.  Since there's no way to guarantee that two windows in the
> same origin are in the same process, Chrome would need to always set it to
> null in order to avoid confusing developers (since what process a page is in
> is really an implementation detail).
>
> But, as far as I can tell, Safari is the only browser that currently
> provides this.  I suspect that as other multi-process implementations are
> developed, they'll run into the same issue.  And, even if they can
> technically provide synchronous access to another processes Window object,
> there are _very_ strong arguments against it.  So, can we please remove the
> source attribute from storage events?
>
>
+1, the "source" attribute is not something we will implement in Chrome.



>
> One other question: is the URL attribute supposed to be the same as
> documentURI or location.href?  I ask because WebKit currently uses the
> documentURI but if this were the correct behavior, I would have expected the
> spec to make that more clear.
>

This is interesting since documentURI is a read/write property:
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-documentURI

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091015/8aa93b40/attachment.htm>
Received on Thursday, 15 October 2009 12:21:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC