[webkit-dev] GlobalScript in WebKit

[Ian Hickson]

On Tue, 1 Dec 2009, Michael Davidson wrote:
> On Tue, Dec 1, 2009 at 11:51 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Tue, 1 Dec 2009, Michael Davidson wrote:
> > > No, we definitely want to share network connections. We'd like users 
> > > to be able to have an arbitrary number of Gmail windows open without 
> > > running into the browser connection limit.
> >
> > SharedScript doesn't give you that. Only a singleton mechanism can 
> > give you that.
> 
> Assuming that the same-process hinting works, it will give us that.

The process hinting is not a guarantee. It is trivial to come up with 
situations where different documents from the same origin are required to 
end up in different processes. Furthermore, as a user, I would personally 
much rather every GMail instance I open end up in a different process, for 
the same reason that I'd like GMail and Google Calendar in different 
instances, and Google Calendar and Google Search in different processes, 
and Search and pages I get to from Search in different processes.


> At the very least, it will vastly improve the situation we have today.

Either you "definitely want to share network connections", in which case 
it doesn't give you what you want, or you don't need to share network 
connections, in which case it seems no better than an <iframe>.


> The iGoogle gadget that you mention later would not use SharedScript, 
> FWIW.

Sure, but if it opens a true GMail window, that GMail window would have to 
end up in the same process as the parent (so that the opener can be 
accessed), which means it wouldn't be the same process as other GMail 
tabs. It doesn't have to be an iGoogle gadget; any page that 
window.open()s GMail would be in this situation as far as I can tell.


> I agree that anything that lives in an iframe is going to cause problems 
> for SharedScript, but Gmail (like many webapps where having the URL 
> exposed to the user is very important) doesn't allow itself to be in an 
> iframe.

It prevents it using script, which is too late since the process selection 
happens long before the script runs.


> > It seems that you could just create an <iframe> instead of the 
> > SharedScript, and pass it around onunload.
>
> Can an iframe live independently of its creating document?

Per spec, yes, so long as it is owned by a living document it'll keep 
existing. It should even work in browsers so long as you actually keep the 
iframe grafted to an existing Window's Document -- hence the "pass it 
around onunload" to keep it alive.


> The goal is not to mislead people into thinking that SharedScript is 
> bulletproof sharing, which is why the spec says that sharing might fail.

Yes, but people will think that's what it does, regardless of what it 
does, because in most testing that's what it will do. It's like the 
localStorage debacle -- we have to offer consistency guarantees because 
people will assume them regardless of what the spec says.



Anyway, I'm not trying to discourage experimentation here; I just wanted 
to make it clear that SharedScript doesn't solve the shared networking 
problem, because it can never be guarenteed to be a singleton -- indeed, 
from the user's perspective, it would be undesireable for it to be 
possible to make the browser always put all tabs from one origin into the 
same process even if it was possible.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'