<br><br><div class="gmail_quote">On Tue, Jul 28, 2009 at 2:12 AM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiak<<a href="mailto:mjs@apple.com">mjs@apple.com</a>> wrote:<br>
><br>
> On Jul 27, 2009, at 10:51 PM, David Levin wrote:<br>
><br>
> It sounds like most of the concerns are about the 2nd part of this proposal:<br>
> allowing a background page to continue running after the visible page has<br>
> been closed.<br>
> However, the first part sounds like it alone would be useful to web<br>
> applications like GMail:<br>
><br>
> The first, which should begenerally useful, is the ability to have a hidden<br>
> HTML/JS page running<br>
> in the background that can access the DOM of visible windows. This<br>
> page should be accessible from windows that the user navigates to. We<br>
> call this background Javascript window a "shared context" or a<br>
> "background page". This will enable multiple instances of a web app<br>
> (e.g. tearoff windows in Gmail) to cleanly access the same user state<br>
> no matter which windows are open.<br>
><br>
> + restrict things to the same security origin.<br>
> It sounds similar in concept to a share worker except that it runs in the<br>
> main thread and is more concerned with dom manipulation/state while workers<br>
> have typically been thought of as allowing background processing.<br>
> It seems that the lifetime of this could be scoped, so that it dies when it<br>
> isn't referenced (in a similar way to how shared worker lifetime is scoped).<br>
><br>
> This idea actually sounds reasonably ok, and I think I once proposed<br>
> something like this as an alternative to shared workers as the way for<br>
> multiple app instances to share state and computation.<br>
> It's really the bit about invisibly continuing to run once all related web<br>
> pages are closed that I would worry about the security issues.<br>
<br>
</div></div>The only concern I see with this is that it permanently forces all<br>
windows from the same domain to run in the same process. As things<br>
stand today, if the user opens two tabs (or windows) and navigates to<br>
the two different pages on <a href="http://www.example.com" target="_blank">www.example.com</a>, then a browser could if it<br>
so wished use separate processes to run those two pages. If we enabled<br>
this API the two pages would have to run in the same process, even if<br>
neither page actually used this new API.<br>
<font color="#888888"><br>
/ Jonas</font></blockquote><div><br></div><div>There are conflicting requirements along these lines that would need to be resolved...</div><div><br></div><div>1) A nested iframe needs to run in the same process as its containing page.</div>
<div>2) A shared context needs to run in the same process as its client pages.</div><div><br></div><div>... but what if a nested iframe document in processA connects to a sharedContext that has already been loaded into processB. Somethings gotta give.</div>
<div><br></div><div>What if a sharedContext isn't gauranteed to be a singleton in the browser. A browser can provide best effort at co-locating pages and sharedContexts, but it can't gaurantee that, and the spec respects that.</div>
<div><br></div><div>The lesser gaurantee is that all directly scriptable pages (those from a given set of related browsing contexts) WILL share the same sharedContext (should the refer to it).</div><div><br></div><div><br>
</div><div> </div></div><br>