[webkit-dev] GlobalScript in WebKit
ian at hixie.ch
Tue Dec 1 12:20:49 PST 2009
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,
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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the webkit-dev