> I actually just did a quick test, and I am unsure how I can actually open two > windows in such a way that Chrome would end up using a single SharedScript > instance -- both new window and new tab result in separate processes, the > only logical case that would allow multiple windows to end up sharing an > instance (and thus gaining any benefit at all from this feature) would be by > opening a window from an original source page, in which case an invisible > iframe could trivially be passed around, and has all of the advantages of > SharedScript, none of the disadvantages, and works in all existing browsers. > > The usage of SharedScript is a strong hint to the browser that future tabs > for that origin should be opened in the same process. With such a heuristic, > you only run into trouble when a particular origin doesn't immediately use > the SharedScript and a user opens up another tab in the mean time. This > could be mitigated by the browser saving which origins use SharedScript > somewhere. > > Has anyone really sat down and compared the use cases given in the spec to > the behaviour of users? eg. to see if the model you're talking about would > actually provide any real benefit in real world usage > > The spec was co-written by real world users (gmail engineers).
Engineers are not everyday users -- I am not referring to developers (i've been fairly careful in this discussion to not conflate developers with end users), I am referring to actual end users and their interaction with the browser. If a SharedScript is meant to indicate that a new process shouldn't been spawned it seems reasonable to require SharedScripts actually be shared. --Oliver
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
