On Tue, Jul 28, 2009 at 2:12 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiak<m...@apple.com> wrote: > > > > On Jul 27, 2009, at 10:51 PM, David Levin wrote: > > > > It sounds like most of the concerns are about the 2nd part of this > proposal: > > allowing a background page to continue running after the visible page has > > been closed. > > However, the first part sounds like it alone would be useful to web > > applications like GMail: > > > > The first, which should begenerally useful, is the ability to have a > hidden > > HTML/JS page running > > in the background that can access the DOM of visible windows. This > > page should be accessible from windows that the user navigates to. We > > call this background Javascript window a "shared context" or a > > "background page". This will enable multiple instances of a web app > > (e.g. tearoff windows in Gmail) to cleanly access the same user state > > no matter which windows are open. > > > > + restrict things to the same security origin. > > It sounds similar in concept to a share worker except that it runs in the > > main thread and is more concerned with dom manipulation/state while > workers > > have typically been thought of as allowing background processing. > > It seems that the lifetime of this could be scoped, so that it dies when > it > > isn't referenced (in a similar way to how shared worker lifetime is > scoped). > > > > This idea actually sounds reasonably ok, and I think I once proposed > > something like this as an alternative to shared workers as the way for > > multiple app instances to share state and computation. > > It's really the bit about invisibly continuing to run once all related > web > > pages are closed that I would worry about the security issues. > > The only concern I see with this is that it permanently forces all > windows from the same domain to run in the same process. As things > stand today, if the user opens two tabs (or windows) and navigates to > the two different pages on www.example.com, then a browser could if it > so wished use separate processes to run those two pages. If we enabled > this API the two pages would have to run in the same process, even if > neither page actually used this new API. > > / Jonas There are conflicting requirements along these lines that would need to be resolved... 1) A nested iframe needs to run in the same process as its containing page. 2) A shared context needs to run in the same process as its client pages. ... but what if a nested iframe document in processA connects to a sharedContext that has already been loaded into processB. Somethings gotta give. 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. 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).